Slashdot Mirror
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.'"
We won't know until we know what Oracle plans to do with InnoDB. Oracle is having trouble competing with MySQL. Look at the last realease that was free to use and deploy. They ( As does MSSQL ) have to compete withh MySQL.
Oracle could repackage InnDB as a gateway db, with Oracle compatibility to get users hooked on an Oracle product that would later lead to sales.
IMHO, Oracle does not need the technology, as Oracle has tons of capabilities. There is probably another reason why they bought InnoDB. We won't know what they will do until they actually plan to do.
-- I doubt, therefore I might be.
The problem is *not* that the storage engines are modular. That's an innovative implementation decision, and it is not inherently bad.
What causes the problems for some people is the MySQL exposes a different behavior to the user for each storage engine. In other words, the storage engine is not abstracted away from the user, but just the opposite.
Examples include foreign key and transaction behavior on MyISAM tables (that is, the commands are ignored by a MyISAM table) versus the behavior on an InnoDB table (where the commands function as you might expect).
Social scientists are inspired by theories; scientists are humbled by facts.
Exactly. What do you think *I* use? Hint: It starts with a P.....
This being said, I think that this discussion is important because it helps clear up *why* this acquisition is so bad for MySQL.
There are some other things that bother me about this response:
1) It took so long to occur.
2) No specific details. So this is entirely vaporware as far as I can see.
3) There are *no* alternatives to InnoDB on MySQL (BDB has performance issues, etc).
LedgerSMB: Open source Accounting/ERP
2. PostgreSQL has a huge lead here over MySQL, that is, as an community-driven open source project. They already have a large distributed network of developers, whereas I understand MySQL has been developed almost entirely by the AB.
It will take a long time to reach the robustness of the PostgreSQL development project, and I bet a lot of people might switch at this juncture.
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.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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.
Flying is easy, just throw yourself at the ground and miss. -Douglas Adams
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.
Social scientists are inspired by theories; scientists are humbled by facts.
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.
Yes, that's RDBMS theory.
Then the DBMS will use the path which is most optimized for the request.
In the real world, there is no such thing as "most optimized". Optimized for what? Reliability? Portability? Correctness? Features? Code maintenance? Speed? Memory usage? Disk usage? Throughput? Interactivity? Uptime? Least sysadmin work? I could probably go on, but I think you get the picture...
So, the fact that MySql is better for some tasks than Oracle, is a flaw in both engines, and supposedly one that both are working to fix.
Yes, but that doesn't mean that it's ever going to be fixed in either of the engines. The fact that buses have more space, and bicycles are easier to park, doesn't mean that one day we will have something that combines the advantages of both.
Just to give an example, since the user, doesn't see where and how his data is stored, Oracle for example, can use MySql's engine internally, when it detect situations for which MySql's engine is optimized, and switch to Oracle's engine, when the situation change, all hidden from the user, of course this is all in theory. It can be factually impossible to implement such a thing.
Just like it's factually impossible for the bus to use the bicycles internal engine when you decide it's time to find a parking spot.
The key phrase to google is "disruptive technology". Clayton Christensen is the expert on the topic.
Different kind of free. You do know there's more than one kind of free, don't you?
Anyway, Oracle XE is actually pretty nice, particularly if you want to throw together a quick web-based app. I wish I could put something together with PostgreSQL/PHP (or whatever) as quickly as I could with Oracle's web forms designer.
Us as technicians may perform this discussion. Parent has a point.
Now, reality comes in. Get your end users to fill in the forms. Is that done properly ? As far as programs are concerned, they can do that, but, it is not their integrity we need a database for.
Real-life integrity can only be obtained by estimating the integrity of the weakest part of the chain user-application-db. I suppose it's not the database that is critical in most cases. It leaves you to choose any db you think is reasonable for the job. But remember: garbage in, garbage out.
That's an interesting take, but a little unfair.
Many people use LAMP because you can get a website hosted for next to nothing using it.
Most of the really cheap places I've seen offer either win32/asp/IIS/sqlserver or LAMP.
There are plenty of things I don't like about mysql 4.x (no sequences, no subselects, etc.) and plenty of things I don't like about php 4.x (lack of type hinting on primitives, no standard DB connectivity layer, etc.). But the workarounds aren't really that bad.
I could be much more productive with J2EE and oracle, but I'm not gonna get someone to host my sites for just a few bucks a month.
"If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
It may be accurate to say that while it is theoretically possible to design a database such that all data can be represented, and no nulls are present or required, the availability of NULL has real practical value (but Oracle making empty string be the same is still stupid).
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.
The BDB handler could be updated, and I don't think that would be that much of a problem. As for Berkeley-DB itself it is (very) actively developed (http://www.sleepycat.com/) and it is surely more widely deployed and more stable than InnoDB (Berkeley-DB has 200 million deployments compared to only 5 million MySQL deployments). As for the "huge performance cost", I really doubt there is such a thing.
If you don't fail at least 90 percent of the time, you're not aiming high enough. (Alan Kay)