MySQL to Counter Oracle's Purchase of InnoDB

Miff writes "Computerworld is reporting that MySQL is hoping to counter Oracle's acquisition of InnoDB by providing its customers with an alternative." From the article: "Axmark said the storage engine is 'pluggable,' meaning other storage engines can be substituted instead. He said the code for InnoDB is under the GPL (General Public License), so 'the code is always out there. It will always be out there.'"

Comments

InnoDB

[damiceious]

So, I'm not an expert on the GPL, but it sounds like we're looking at a fork? Where the OSS community gets to continue to use a public GPL`ed version, and Oracle will develop what they bought? I wouldn't think that Oracle would undermine MySql OS'ness, but the article said without a continuance of their license Mysql Development could slow down, or be setback. Maybe someone can explaint the highlights of the GPL that apply here?

Re:InnoDB

[fbg111]

A few questions come to mind:

1. Does Oracle need InnoDB? Would Oracle gain features or capabilities they don't already have by incorporating it into their database? If so, then perhaps we're looking at a fork.

2. If InnoDB is forked, does MySQL have the developer talent to continue advancing InnoDB, or will the OSS community do it for them, or will it stagnate?

Re:InnoDB

[linuxhansl]

The issue is this:
MySQL makes some of its revenue by selling non-open-source licenses to customers who, for whatever reason, do not widh to publish their contribution.

Now, you can only release code under any license of your choice if you own all the copyrights.

Once Oracle owns the copyrights to InnoDB (and if Oracle does not extend the same relicensing rights to MySQL that InnoDB did), the only option MySQL has is redistributing a derived work under the GPL, they are legally no longer allowed to release under any other license. This in turn cuts off one of their revenue streams.

Silly

[jimmyhat3939]

I think this battle between Oracle and MySql is kind of silly. The two databases serve different purposes:

• MySql is excellent for anything ranging from the casual user (a few tables, 1000 rows in each) up to fairly complex transactional work (a small or medium-sized company).
• Oracle has a bunch of extra features, like an excellent fuzzy text search engine and certain optimizers for complex queries that MySql doesn't (and IMHO shouldn't) have. Oracle is the DB of choice for non-M$ medium-to-large databases.

There are other differences. Setup and configuration of MySql is much simpler, and you don't have to go as crazy creating complex partition schemes on your hard disks to get decent performance. But again, that's as it should be -- for simpler projects you want the free alternative.

--
Free 411! 1-800-411-SAVE

Re:Silly

[Master of Transhuman]

An empty string is a value; a NULL is the absence of a value.

In fact, in relational theory, according to Chris Date (although Codd himself supported the concept to some degree), NULLs shouldn't exist. This is because a table expresses facts - logical expressions - about an entity or a relationship, and a NULL is not a fact, it is the absence of a fact. An entity or relation about which you do not know the relevant facts should not be in a table which expresses facts about that entity or relation.

NULLS also lead to screwed-up SELECT results sometimes and worse, sometimes you can't detect that the results are screwed up.

This usually produces a religious war discussion, and I don't know enough to argue the case either way, so I won't say anything more about it. I'll just say that with Codd dead, Chris Date is the main man when it comes to relational theory, as far as I can tell, and he makes a good argument against NULLS.

Pick up his book "Database in Depth" published by O'Reilly, which is not really a book for newbies, but does have some fairly clear explanations of the issues. It's smaller and cheaper (by about three-plus times - $30 vs $105) than his college textbook on the subject.

Re:Silly

[fbg111]

It's a bit simpler - Oracle is for anyone who knows what data integrity is and requires it, MySQL is for anyone else. PostgreSQL is the free, acceptable alternative to Oracle.

Re:Silly

[jadavis]

MySQL and Oracle compete like public transportation and the automotive industry[1]. They're different concepts used in very different ways, so they are not direct competitors like Ford and Chevy. However, one is still an alternative to the other, so they are indirect competitors.

In some ways indirect competition is more destructive because it's a positive feedback system. The auto industry takes off in the U.S., so we build lots of infrastructure that make cars more desirable, which means more cars are purchased. However, if one person purchases a Ford that doesn't reduce the desirability of a Chevy to someone else.

That extends to databases easily. For the sake of argument, let's say MySQL users tend to put more code in the applications, and less logic in the database than Oracle users. Then their application no longer has much need for Oracle, reducing the desirability of Oracle, leading to (perhaps) another application built upon the same database system.

[1] I am making a very loose analogy. If you're trying to figure out which database I'm calling public transportation, and why, you've already put more thought into this than I have.

The real problem

[einhverfr]

MySQL does not provide a transaction-safe store free of licensing overhead. Commercial licensing of BDB, SAP-DB, and InnoDB all require relicensing agreements.

These being availble for use under the GPL and similar licenses helps out everyone who uses MySQL under the GPL. But it doesn't help anyone else out, including MySQL. What MySQL needs is the ability to add something like MVCC to a table type that they own. Oh wait that will never work because MyISAM should be pretty much at odds with the whole concept. I guess it is time to build one from scratch.

So the inevitable outcome is that MySQL will probably have to write a storage engine from scratch that meets all the needs that InnoDB filled.

Re:Not silly at all

[Master of Transhuman]

Actually, neither one of them implicates relational theory properly. Aside from the InnoDB engine, most of MySQL is pathetically incomplete. Without InnoDB, MySQL is worthless with regard to referential integrity, which is a showstopper for any database that requires multiple tables related to each other.

If the company building the Trans-Relational database ever gets off the ground (or failing that, goes open source), perhaps both of them (along with Sybase, SQL Server, Informix, and the OOP DBMSs) will be put out to pasture. The claimed capabilities of that system, implementing a very relationally complete system, would bury even Oracle eventually, if not immediately.

Anybody have any real background info on why the company developing the Transrelational system is having legal and/or financial trouble? Nothing concrete appears to be available on the DbDebunk site or via Google. The whole thing appears to have been hanging fire for a long time.

The name of the new storage engine is...

[adnonsense]

MyFireGreSQL.

Re:Which Database?

[dkf]

postgresql->oracle is the best combo in the book. Every project my company has touched in the last 7 years started with postgresql and if we ran into one of the limitations in postgresql, switching to oracle was painless.

I'd agree with that, and point out that SQLite is there for people who come in at the small end of PostgreSQL. I'm told (by the SQLite author no less) that upgrading to postgresql is easy when you want to take that step. And it is public domain.

Between them, sqlite->postgresql->oracle offer a full database solution for everything from "I want a better config file for my personal scripts" to "I have to run a mission-critical database for a Fortune 500 corporation", and you can't say much fairer than that.

Re:Patent Threat

[joto]

If InnoDB contains patented technology that Oracle now owns as a result of their acquisition of InnoDB, isn't that a moot point since InnoDB already released that stuff under the GPL?

No. Repeat after me: "patents have nothing to do with copyright!". Write it on the chalkboard 100 times...

There could be patents covering the GPL-licensed code, which InnoDB might not have enforced. Of course, thinking in this way is almost paranoid, but it has happened before, remember GIF?

No matter how GPL'd the code is, if it violates patents, it is illegal to distribute in countries where that patent is valid. If you doubt me, the text of the GPL license itself spells this out for you. And even if you already have a copy, unless it comes with a patent license, it's illegal to run as well.

Original reasons for using MySQL replaced by...

[Anonymous Coward]

When many people started using MySQL over other choices, the landscape was quite different.

* PostgreSQL wasn't available in a native version on Windows and their developers were still mastering the codebase they inherited (they mastered it around 7.3, before that they tiptoed around making massive changes).

* Firebird wasn't open sourced yet (before summer 2000).

* and SQLite wasn't released either (before summer 2000).

The above 3 conditions are no longer valid.

Many of us use MySQL because so many other software packages are already designed to work with it. Like Windows, it doesn't matter even if better alternatives exist because this one reason alone is most compelling if the software is "good enough".

In other words, the original technical reasons for choosing MySQL over others has been replaced by a compelling new reason: the same reason many people use Microsoft Windows today.

In a nutshell:

* If I want a super fastest lookup table without SQL, I'll use something like cdb or tinycdb.

* If I want a fast and simple database requiring only a tiny subset of SQL, I'll use something like SQLite.

* If I want a modern, full-featured, and free rdbms/ordbms, then I'll use PostgreSQL.

* If I want compatibility with most 3rd-party software, then I'll use MySQL.

Re:Other storage engines compared

[TheRaven64]

A lot of things where MySQL is used really don't need a database. What they need is something like VMS's structured files - something slightly more abstract than an arbitrary stream of bytes, but not much. In these cases, SQLite might be a better choice than PostgreSQL, although I'd still recommend PostgreSQL to anyone who actually needs a database.