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.'"
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.
LedgerSMB: Open source Accounting/ERP
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
LedgerSMB: Open source Accounting/ERP
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.
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.
LedgerSMB: Open source Accounting/ERP
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.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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.
In case you didn't know, Oracle are now offering a free version of 10g: Oracle Database 10g Express Edition
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.
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.
"Little does he know, but there is no 'I' in 'Idiot'!"
I'm not sure that anywhere in the theory of relational databases (?? not sure how that relates to relational theory) it says anything about optimisation or performance of database engines. Much as the Java standard doesn't mean that all JVM perform in the same way, or compilers all produce identical machine code from the same high level language.
The whole point of relational theory is more based around data modelling and normalization - providing a mathematically proven set of guidelines to remove duplication and ensure integrity.
SQL was the first attempt to build a working language based on relational theory - i.e. that would be useful for accessing such a model - think of it as a proof of concept. Unfortunately, by becoming the defacto standard, it's become a bit like Pascal (and BASIC) was in the 80s/early 90s (a language popular despite it's flaws rather than because of it's strengths).
It also took a long time for anyone to make a performant RDBMS that used SQL - Oracle got big for a reason. Even then it became rapidly evident that procedural extensions were required on the server, rather than the 'declarative on DBMS, procedural control on the client' model that was touted in theory. (Even if SQL worked perfectly this would still be inefficient).
As for whether RDBMS should optimise the same SQL in a consistent way - it's worth considering the different ways a single statement gets optimized on Oracle. The same SQL will create a different optimisation path if you tell the optimiser you want first rows (optimize for response time) or all rows (optimize for throughput). In addition specifying that you want 'first 20 rows' rather than 'optimise for first rows' and then only querying 20 from your client will ALSO give a slightly different optimisation. And that's without going into streaming queries, etc.
The point is that this is completely outside the scope of the SQL language definition (which IS declarative - what do you want, not how it should be done) but to work effectively the optimiser needs some pragmatic information about what you want to do.
One of the key differences between mySQL and Oracle is that Oracle is optimised as a highly concurrent transactional database - which is overkill for 95% of the situations mySQL is used for. However this is again the sort of outside contextual information that keeps us humans employed. Much like knowing when to write something in perl and when to use C.
All that said, having worked with navigational databases, SQL was/is a definite step forward, and removes a LOT of the work for most programmers in terms of needing to know how data is stored.
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.
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.
Infuriate left and right
> 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.
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.
Flying is easy, just throw yourself at the ground and miss. -Douglas Adams