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

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

[llefler]

MySQL's got three big great things going for it: raw disgusting speed, relative simplicity to set up and administer, and the whole dual-license thing.

From my perspective, MySQL has two things over Postgres. MySQLAdministrator and they don't do silly things with case sensitivity.

OTOH, they only have one advantage over Firebird, MySQLAdministrator. I keep hoping that the guys over at "Firebird - Relational Database for the New Millenium" will wake up and get some good tools out there. If FlameRobin ever matures, I'll wipe MySQL from my systems in a heartbeat.

What's not to like? The job of the database it to maintain data integrity. MySQL falls down in a number of ways. Who cares what license it has if your data isn't safe.

Speed has never been an issue for me, but then, I'm not trying to use my workstation from two generations ago as a database server.

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:Silly

[Dual_View]

That's the whole point. They're databases, and that's where the common ground stops. "Apples and oranges", is the phrase that comes to mind. They cater to different subsets of the public. Right now, this "competition" of theirs is just a self-imposed illusion.

Then again, you bring up another good point in and of itself. It's very likely that both MySQL and Oracle are looking at each other and considering how to market to the other's primary segment of clients.

But also, both databases are open-source. This should make things even more fascinating, unless the open-source community itself starts taking sides.

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.

Oracle are now offering a free version of their DB

[philj]

In case you didn't know, Oracle are now offering a free version of 10g: Oracle Database 10g Express Edition

Indexing component is key for performance

[aharth]

From experiments with my database-like system in Java (http://sw.deri.org/2004/06/yars/yars.html), I learned the hard way that the indexing/storage component is the key piece for any system dealing with large amounts of data. Performance depends to a great extent to the underlying storage mechanisms used (and different implementations of e.g. B+-Trees vary greatly in performance and functionality). Implementing a fast B+-Tree with transactions is a non-trivial task.

Let's hope MySQL AB. find a good replacement for InnoDB.

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.

Don't think so

[A nonymous Coward]

GPL prevents redistribution, not use. Companies only need to buy the commercial MySQL license if they want to distribute closed source programs. Internal usage doesn't care a whit.

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:Silly

[fbg111]

But remember: garbage in, garbage out.

True, but the purpose of the relational database is to prevent the 'garbage in' part. It relies upon the Data Admin or Data Architect (not the DBA, which is different) knowing the data in the problem domain thoroughly enough to design the database and its constraints so that garbage is not accepted, and the only data that goes in does so according to well-considered business rules and to the relational algebra of the model. Putting data integrity constraints in the db means that every app that connects with that db is forced to adhere to the same constraints, so that even if the app developers on one particular app screw up and forget to validate a particular input field correctly, the bad data is still prevented by the DB's constraints. The DB will throw an error and the app will fail on the insert, and good developers will build into their apps try/catch logic and other methods of gracefully handling such errors. The DA and DBA's job responsibility is maintaining and ensuring data integrity, and building the constraints into the DB is the method of assuring that. In a nutshell, there should never be 'garbage in', and hence no 'garbage out' either.