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

[einhverfr]

FWIW, Oracle has had their competitive sights on MySQL for some time. In 2000 iirc, they started releasing migration path tools to help people move from MySQL to Oracle. It is within this context that I see the InnoDB acquisition taking place.

(BTW, I don't like Oracle. Any RDBMS that treats an empty string and a NULL as equivalent should be avoided.)

Oracle and MySQL compete in a number of interesting and important markets, and as we all know, application mandates have a tendency to grow as do datasets. So people see MySQL as a growing RDBMS and use it and sometimes get trapped into it by weird MySQLism's. This keeps people with the RDBMS when it is not even close to meeting real requirements and having to code around the deficiencies.

Whether the markets overlap and to what extent, Oracle sees MySQL as a strategic threat.

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

[Baricom]

The two value types can have different semantic meanings. Typically, empty strings signify that no value applies for the column, while NULLs signify that the value is unknown.

Say you have a table with a MiddleName column. Using the rule above, if you store NULL, that means you don't know what the person's middle name is. in contrast, if you store the empty string, it means the person doesn't have a middle name.

The distinction is controversial, and some database administrators feel that distinguishing between NULL and the empty string adds unnecessary complexity to an application.

Disclaimer: While I'm confident that I know a little more about databases than the average developer, IANADBA.

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.

Other storage engines compared

[NickDoulas]

Does anyone know the practical difference in using other storage engines? For example, how does using Berkeley DB (http://dev.mysql.com/doc/refman/5.0/en/bdb-storag e-engine.html) compare?

Also, how typical are non-InnoDB configurations of MySQL?

Re:Other storage engines compared

[einhverfr]

The BDB handler has been barely maintained. All the benchmarks I have seen show BDB losing out to pretty much every other storage engine. You get transactions and advanced capability, but at a huge performance cost.

Use PostgreSQL and you will be happier :-)

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.

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:The real problem

[jsonn]

Update your facts. There are exactly two areas where MySQL is noticable faster than PostgreSQL. Those are connection time and non-transactional queries. If you depend on the former -- rewrite your programs, they are bogus. If you depend on the second, pray that the load will not increase enough to kill your database either by inconsistencies or locking. As soon as it comes to complex queries, PostgreSQL runs circles around MySQL.

MySQL 5 is still lacking a lot, most importantly in the I of ACID. It does not ensure integrety, it does things behind the scene which do not match the SQL commands. Silently trunkating data is evil, just like creating invalid dates. No excuses, MySQL just sucks in that department. Besides, stuff like the query cache don't belong into the database server. They belong into the middleware, since that is exactly where the necessary context is.

Last but not least, I do consider PostgreSQL to be much easier to administrate. I have central authentication support, I don't need magic commands to update the internal state of the server etc. It just works.

The LAMP argument is useless. Neither is PHP often a good choice for good web programming, nor is Apache necessarily the best web server. Just because a lot of people ask for it, doesn't make it good. You know the most popular Operating System out there, don't you?

Re:The real problem

[rbanffy]

The single biggest problem with the MP part of the LAMP stack is that both PHP and MySQL attract the wrong kind of developers.

The developers who are willing to live with the shortcomings of PHP and MySQL should consider if they really want to develop software. They are just like the people who are willing to live with the shortcomings of VB6 and Jet databases - they live with them because they know nothing else. While the query language of MySQL has improved with the latest releases, it is still not quite on par with, say, PostgreSQL. Do a somewhat complex join and you will see MySQL's speed go down the drain. See what happens when you have lots of concurrent long-running transactions.

MySQL screams "cheap" since its beginning and no amount of engineering will make it look well built. It may look "overbuilt", at best.

Re:Not silly at all

[jimmyhat3939]

It turns out that configuration is a difficult task and so there's no way to obfuscate that from the DBA.

Also, there exist plenty of situations where there are absolute tradeoffs. Making something fast in one case makes it slow in another. While it would be nice for the DB to be able to figure all that out beforehand, in practice it's impossible.

Take a case where a bunch of precomputation is required to make an operation fast (a particular kind of indexing, for example). You have to instruct the DB to do that precomputation. It can't know in advance that you'll be doing a lot of queries that require it.

Bottom line is that, though the goal of SQL is to make the "how" hidden from the user, in practice this is impossible and not even desirable.

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:MySQL needs to build their own storage engine

[Master of Transhuman]

The problem is that if you are developing a database with multiple tables related to each other (MySQL DOES want to be considered a "relational" database rather than a mere "file handler"), then you have to have referential integrity (or waste time coding referential integrity yourself - I used to do that with FoxPro back in the day, and it's not fun.)

Most of the MySQL engines don't do referential integrity - which makes them worthless for most "real" database efforts. Only InnoDB enforces foreign key constraints.

If the current version of InnoDB in MySQL 5.x is under GPL, and MySQL AB can continue to develop their own fork, it may not be that big a problem. But if they can't, due to patent or other IP issues, MySQL is in big trouble. In fact, for any serious uses, they're history, and everybody would be advised to turn to PostgreSQL or Firebird - or even Ingres.

Firebird in particular is fast and small and would suit the sort of Web applications that MySQL is known for - except that there isn't much support in Firebird for that sort of thing - but it could be added on if people see the need due to MySQL becoming a liability.

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:Which Database?

[kpharmer]

> With Oracle's purchase of Inno-DB and their recent release of a free version of their database software,
> it looks like a war will be shaping up over the low end of the database market.

I think you're completely right there - the big vendors know that the little databases generate cash too - and mindshare. They can't afford to lose it. This is a market-protection plan for them.

> Besides for being open-source, what advantages do PostgreSQL and MySQL have over Oracles' 10g Express,
> Microsoft's SQL Server 2005 Express, and IBM's proposed DB2 Express?

Well, MySQL is tarnished for a few reasons now:
- future is uncertain due to innodb buy-out
- history of inexplicable data quality and exception handling issues
- dual-licensing complexity

Postgresql is looking much better now:
- they had some performance problems 3-4 years ago, but are now well-beyond that
- is completely free
- starting to get picked up within very large commercial applications

In comparison SQL Server express and Oracle express offer:
- a free database for very small applications
- the opportunity to deploy a tiny database, then replace it with a larger one without any application code changes
- opportunity for vendors and shops to reduce the number of supported databases

DB2 Express offers:
- a low-cost database (last I looked it was around $750/server)
- with much more scalability than sqlserver/oracle express versions:
    - no storage limitations
    - partitioning is included (via mdc)
    - just two cpus (don't know if they can be multi-core or not)
    - I think 64-bit memory is supported, but is still limited to 4GB

So, Oracle & SQL Server have one strategy (offer an extremely limited product for free), while DB2 has another (offer a slightly-limited product for less than or about cost of MySQL). IBM might change the DB2 strategy, but I hope they just add a extremely-limited free version, and keep the existing express version.

And this strategy works: I've got oracle, sql server, db2, postgresql, and mysql in our organization, and am standardizing on db2. When we get a small database it uses a cheap db2 license. This keeps my labor costs down (which are far more than the software costs). If it wasn't for the cheaper licensed versions I'd probably be putting all of the small databases on postgresql - and growing that skillbase within the organization.

Re:Not silly at all

[MattW]

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.

As the companies using this pathetic database have noticed, 99.9999% works just fine; especially when your application is aware that you don't have a foreign key constraint and yes, the data may be munged 1 time in 1 billion and need to be cleaned.