Linked by Thom Holwerda on Mon 4th Jan 2010 22:41 UTC
Databases A petition launched in December by MySQL creator Michael 'Monty' Widenius to 'save' the open-source database from Oracle has quickly gained momentum, collecting nearly 17,000 signatures. Widenius on Monday submitted an initial batch of 14,174 signatures to the European Commission, which is conducting an antitrust review of Oracle's acquisition of Sun Microsystems, MySQL's current owner. The petition calls for authorities to block the merger unless Oracle agrees to one of three "solutions", including spinning off MySQL to a third party and releasing all past versions and subsequent editions for the next three years under the Apache 2.0 open-source license.
Thread beginning with comment 402608
To view parent comment, click here.
To read all comments associated with this story, please click here.
google_ninja
Member since:
2006-02-05

A lot of people say this, but I don't buy it. There isn't a major RDBMS out there that doesn't have proprietary extensions, simply because there are massive holes in the spec. For example, there are no stored procs in the spec, sprocs tend to be fairly critical, so as soon as you use one, you are locked in to that vendors implementation.

What is great about MySQL is how simple, fast, and reliable it is. The reason it is simple fast and reliable is because it doesn't do many of the things that other databases do. The reason it is so popular is because most people just need a place to persist data that can be backed up easily, and don't really care about ACID properties that are the real selling point of using an RDBMS in the first place.

Reply Parent Score: 2

computeruser Member since:
2009-07-21

There isn't a major RDBMS out there that doesn't have proprietary extensions, simply because there are massive holes in the spec.

And yet MySQL is one of the least standards compliant databases.

For example, there are no stored procs in the spec, sprocs tend to be fairly critical, so as soon as you use one, you are locked in to that vendors implementation

If stored procedures are so critical, how did MySQL become so popular when it didn't have them until version 5.0?

What is great about MySQL is how simple, fast, and reliable it is.

Simple: definitely not. There are way too many gotchas, and the various storage engines have their own.
Fast: with MyISAM, perhaps. But then you don't get transactions. Hardly simple.
Reliable: definitely not with the non-ACIDic MyISAM.

"simple, fast, and reliable" might be true for H2 (Java embedded database) or perhaps SQLite, for the small subset of typical RDBMS functionality it has.

Reply Parent Score: 1

rycamor Member since:
2005-07-18

Simple: definitely not. There are way too many gotchas, and the various storage engines have their own.
Fast: with MyISAM, perhaps. But then you don't get transactions. Hardly simple.
Reliable: definitely not with the non-ACIDic MyISAM.

"simple, fast, and reliable" might be true for H2 (Java embedded database) or perhaps SQLite, for the small subset of typical RDBMS functionality it has.


Exactly! Ironically, the PostgreSQL codebase is about 85% the size of the MySQL codebase. In speed, PostgreSQL is every bit as fast as MySQL's InnoDB tables, so the only way you get a performance advantage is to use the table type that should be the laughing stock of the DBMS world.

The fact that you have to constantly worry about what storage engine is in use, and which trade-off applies to which storage engine makes developing with MySQL much more complex, unless your app itself is dead simple. Not to mention all the other odd limitations and surprises.

Just a few of the gotchas and trade-offs I have had to work around recently:

- Clustered storage doesn't allow for temp tables, fulltext indexes, and all sorts of other normally expected SQL features.
- InnoDB tables allow for constraints and FK relationships, but don't allow fulltext indexing.
- Subqueries cannot be used in the FROM clause of a view (maddening, since that is one of the most useful things about views)
- resultsets from stored procedures cannot be used in views or subqueries.
- Temporary tables cannot be referred to more than once in a given query in a function or stored procedure, even with an alias (in other words, no self-joins or other advanced queries)
- replication breaks if MySQL is restarted while a temporary table is in use. But because of the limitations on views and stored procedures, a database of any relative complexity needs temp tables all over the place.

These few things I have mentioned off the top of my head have probably resulted in at least TWICE the complexity that would otherwise be required in my application code and database design. I am so looking forward to the days I can use PostgreSQL--or anything sane--once again.

Reply Parent Score: 1

Soulbender Member since:
2005-08-18

A lot of people say this, but I don't buy it


You should. There's a difference between having extensions and creating incompatibilities in the standard syntax.

The reason it is so popular is because most people just need a place to persist data that can be backed up easily, and don't really care about ACID properties that are the real selling point of using an RDBMS in the first place.


True that. For most applications mysql is just used a glorified flat-file storage.

Reply Parent Score: 2