What's the Oracle Trial Against SAP Really About? 160
Ponca City writes "Chris O'Brien writes in the Merucry News that Larry Ellison's lawsuit against bitter rival SAP gives Ellison the opportunity to deliver the final humiliation to his company's greatest foe of the past decade while sending a blunt message to Oracle's next great enemy, Hewlett-Packard: 'This is who you are fighting. This is how determined we are to win. Get ready.' O'Brien writes that it's a crafty bit of psychological warfare that is already having the desired effect. When Oracle decided to subpoena former SAP CEO Léo Apotheker after he was appointed president and CEO of HP, Apotheker decided to stay out of the country to avoid testifying so now we have the bizarre spectacle of the new CEO of the largest technology company in the world unable to show his face in Silicon Valley. Ellison loves to fight. In gaining control of PeopleSoft, Ellison demonstrated the love of combat and confrontation that has made him one of the wealthiest men on the planet. He waged an 18-month hostile takeover bid to acquire the company, and fought off an effort by the US Department of Justice to torpedo the deal. 'Oracle probably could have settled this case [with SAP],' writes O'Brien. 'But why pass up a glorious chance to subpoena Apotheker and send your new opponent running in circles?'"
en.swpat.org (Score:5, Informative)
Rustling up a quick summary here for anyone looking for background:
http://en.swpat.org/wiki/Oracle_v._SAP_(2010,_USA) [swpat.org]
What is this costing the taxpayer? (Score:3, Informative)
"SAP has offered to pay $40 million for the damage it caused and an additional $120 million to cover Oracle's legal bill."
But who pays the salary of the judge and other court personnel? The courthouse building isn't free and neither are its utilities. This can't be cheap.
Re:What is this costing the taxpayer? (Score:3, Informative)
Duh, they (both parties) of course paid court fees.
Re:Beautiful... (Score:3, Informative)
Their RAC database is impressive in that there are no other major databases that support Infiniband, but other than that their software is ancient, slow, archaic and uncompetitive.
You don't seem to be particularly familiar with the merits of the Oracle database server, which is still at least a decade ahead of all of its competitors. I like PostgreSQL, but in most respects it is just starting to achieve the level of flexibility that Oracle had with the release of Oracle 7 some seventeen years ago.
The special thing about RAC is not Infiniband, it is that RAC is one of the only symmetric multi-node relational databases available. The IBM equivalent was until recently only available on mainframes. I am not aware if there are any others.
If that were not the case, given the cost, there would be no new major applications designed around Oracle at all. Or DB2 for that matter.
Re:What is this costing the taxpayer? (Score:1, Informative)
Court filing fees in the US are generally a few tens to hundreds of dollars per case; fees for copies of documents are perhaps 50 cents per page at the most; and fees for transcripts, which can be more than a dollar per page often (or perhaps generally) don't go to the court but to an independent company. They may deter some completely silly lawsuits, but do not defray the cost of having court personnel process documents for, hear, deliberate about, and write about a complicated case. (Of course, the litigants themselves often pay significant taxes over the years which properly cover, among other things, having courts available to address legal problems that may arise.)
Re:HP's biggest mistake (Score:5, Informative)
This isn't my area, but perennial cost cutting was the problem. After a solid start reducing fat and focusing on core missions, old Jack ended up going off the rails simply because the money kept rolling.
His philosophy shared a great deal in common with the a very unpopular practice in modern governance known as a strategy of tensions.
He wanted to keep up to 10% of the talent force on steady march out the door regardless of their performance and regardless of how well things were going. This cost cutting measure depends upon the other 90% not leaping to the conclusion that an arbitrary management will eventually come for them as well... And hoping that they instead believe there was something inferior about the 10%; hoping that they will strive to validate the faith of retention that their fearless leader has placed in them. Not a good situation.
Then there was the idea to cut all involvement in any endeavor where the company was not challenging for the crown of industry leader. This of course removes innovation and cross-pollination leaving the remaining servants absent vision and experience coming from outside their own little box.
Wikipedia claims he was known as Neutron Jack. I think that may be taking it a little too far, but you get the point.
Re:Beautiful... (Score:4, Informative)
Unfortunately, many of these things are only learned through hard experience, working on multiple database platforms and then trying to port what works on one to an alternative.
The biggest difference I already mentioned - symmetric multi-node scalability for a single database. So called "shared nothing" database clusters (different nodes host different tables or table partitions) have been common in proprietary databases for many years. I believe there are variants of PostgreSQL out there that can do that.
Oracle pioneered symmetric "shared everything" relational database clusters with Oracle Parallel Server in the late 80s. I understand IBM did the same thing on mainframes with DB2 on Parallel Sysplex a few years later. PostgreSQL doesn't do symmetric clustering yet, but I imagine it will a few years down the road.
On paper, DB2 (for example) is the rough equivalent of Oracle. In practice, developers and DBAs run into enough obstacles doing simple things like alter table operations that Oracle is much easier to administer once it is set up properly. In addition, in Oracle you can do all sorts of database administration operations online without interrupting running applications. More recent versions can rebuild an index while there are active transactions against a table, for example.
My PostgreSQL experience is a little old. The most annoying problem I had was that numeric types needed to match in queries for the optimizer to work properly. I would join a SMALLINT column to an INTEGER column or literal and the index would be ignored. That may be fixed, I don't know. Oracle by contrast uses a uniform NUMBER type comparable to DECIMAL in most databases for everything, which is very convenient. You can increase the numeric precision or scale of any column in constant time, for example. DB2 traditionally required a table export and reload to do this.
If you store integers in 16 bit fields, it is usually tricky to change them all to 32 bit fields without at least stopping all transactions and rewriting every row (which is what PostgreSQL does). Oracle uses variable precision BCD number storage for everything to avoid that problem. I don't know if active transactions can run against a PostgreSQL table while a column type is being altered or not. In any case, you get the idea.
Oracle has an outstanding cost based query optimizer, that can handle views that are built on top of several other layers of views without much of a problem. I haven't tested that in PostgreSQL lately, but what I could really use with the latter are updateable views that filter on session variables. Oracle has PL/SQL "packages" that can store session specific state. Views can refer to package variables such that they limit the rows delivered to a user in that session, which is extremely handy for making virtual private databases.
There are just lots of these kind of things which have been added to Oracle simply due to a very high end client base willing to pay very high rates for the latest and greatest "enterprise edition" stuff. If you don't need the EE stuff, and don't need lots of cores, Oracle is just about as expensive as any other proprietary database, including relatively weak databases like MySQL (now that Oracle owns it) or commercially supported/tweaked versions of PostgreSQL like EnterpriseDB.