MySQL's Creator On Why the Future Belongs To MariaDB 208
angry tapir writes "When Oracle purchased Sun, many in the open source community were bleak about the future of MySQL. According to MySQL co-creator Michael "Monty" Widenius, these fears have been proven by Oracle's attitude to MySQL and its community. In the wake of the Sun takeover, Monty forked MySQL to create MariaDB, which has picked up momentum (being included by default in Fedora, Open SUSE and, most recently, Slackware). I recently interviewed Monty about what he learned from the MySQL experience and the current state of MariaDB."
Don't forget Arch Linux (Score:5, Informative)
Monty said that? Oh, of course he did... (Score:5, Informative)
The part he left unsaid was "MariaDB is the future because that's where I will make my money".
Remember, this is the guy that tried to get a merger court to give him the rights to MySQL back again after he sold them to Sun for a nice sum of money.
Re:Monty said that? Oh, of course he did... (Score:5, Informative)
http://monty-says.blogspot.co.uk/2009/12/help-saving-mysql.html [blogspot.co.uk]
http://monty-says.blogspot.co.uk/2009/12/help-keep-internet-free.html [blogspot.co.uk]
http://monty-says.blogspot.co.uk/2009/10/importance-of-license-model-of-mysql-or.html [blogspot.co.uk]
why not just use postgres? (Score:5, Informative)
why not just use postgres?
jeez
Many providers don't offer this in their cheap standard package. That's a major problem for Postgres I think. Then many popular webapps like Wordpress or Magento are mysql only, and I don't think it will happen soon that they will work with Postgres. Oh and if they did, most of their plugins won't work, so nobody will make the move.
Re:stirring the pot (Score:5, Informative)
Re:Monty said that? Oh, of course he did... (Score:5, Informative)
I believe he is referring to the efforts to divest the MySQL trademark and copyright from Oracle as a condition of the acquisition of Sun by Oracle by EU courts. Not very nefarious as it was under the assumption that Oracle would destroy MySQLs viability in the future.
The more interesting part [pcworld.com] of that whole issue was when you look at how the US pressured the EU court to approve the merger unconditionally.
Re:What's Oracle doing so badly? (Score:5, Informative)
Re:god (Score:5, Informative)
why not just use postgres?
jeez
Ironically, the fact that PostgreSQL is a better DB makes it easier to convert from PostgreSQL to MySQL than the reverse. MySQL attempts to error correct your SQL queries while PostgreSQL is much more strict. The upshot of this is that queries that works and are tested in MySQL have a good chance of not working and need to be checked (doubly so if the original programmer tried to be clever).
The company I work for is in the beginnings of a transition. Our PHP and C software have an easy switch to convert between the two databases but now we get to check to make sure every query works and returns the same results in both databases. The cleanup of our queries will be good in the long term but for now it's a LOT of work.
Re:In other words (Score:5, Informative)
Re:Why "Maria" DB? (Score:5, Informative)
Michael Widenius has two daughters, My and Maria.
http://en.wikipedia.org/wiki/Michael_Widenius [wikipedia.org]
Re:Me, too! (Score:5, Informative)
Depends on what the code is. For example, if you've been using PDO in PHP, then probably no problem, since there is an abstraction layer between your code and the actual SQL calls.
Re:stirring the pot (Score:4, Informative)
Re:Me, too! (Score:5, Informative)
It's a MySQL problem. Postgres is SQL standards compliant, MySQL isn't.
Re:god (Score:5, Informative)
The problem is that MySQL only looks easier on the surface. I'm not talking about badly optimized, I'm talking about queries are ambiguous and In many cases where MySQL should return an error it simply returns wrong data. The downside when trying to convert is that in a few cases we have found so far, the original author had simply kept modifying the query until the output until it roughly sent what it was supposed to and the result of that is unmaintainable code that everyone is afraid to touch.
Re:What's Oracle doing so badly? (Score:5, Informative)
Oracle don't want you to install it. They want you to employ an expensive consultant who knows how to install it.
Re:10.0.1 Alpha (Score:3, Informative)
Except that he can't. MariaDB is a fork of MySQL and as such Monty does not own the publishing rights in order to sell them. He could sell a "license" of MariaDB, just as he could also sell a "license" of Linux, but he can't alter the licensing of MariaDB any more than he can alter the licensing of MySQL anymore, nor can he sell those privileges to others.
Re:Me, too! (Score:2, Informative)
It's more of a database problem in general. The ANSI SQL Standard isn't broad enough. If the situation was reversed, if you had a project written specifically for PostgreSQL, you wouldn't be able to drop in MySQL, either. Or if the project was written for Oracle, you wouldn't be able to drop in MS SQL Server. As some people have mentioned already, MySQL isn't 100% ANSI SQL compliant. But even if it was, you still couldn't drop it in place more than likely, unless it was a very simple application and didn't use any functionality outside of the ANSI SQL standard.
AND, even if THAT were true, it would still depend on how it was written. Some languages, like .Net/VB or Perl, force you to use a sort of middle layer in the code. Basically you write code that talks to A database, but not specifically WHICH database. PHP, however, is only just recently adding this sort of functionality. If your project happens to be written in PHP (you didn't say but it's likely given the popularity of PHP) and has been around for awhile, then it's likely that it's written to talk to a SPECIFIC database, and not a database in general.
This means that even if the databases and the SQL used were perfectly compatible, it STILL wouldn't work because the code is written specifically to talk to MySQL and only MySQL. If this is the case, then the fault wouldn't be EITHER database, but the code (and perhaps to some degree the language used).
By the way, going based on the number of projects that outnumber one or the other isn't a good indicator. MySQL was pushed as an easy to configure/use sort of thing. A lot of hosting companies sold products based on having a LAMP (Linux, Apache, MySQL, PHP) stack, for example. Thus we have a LOT of projects that are written in PHP and written for MySQL. That doesn't make either better (nor can you infer the opposite). It just means it was marketed really well. It's like saying MS Windows is the best operating system out there because that is what most people use, or that whatever famous pop artist has written the best music ever because they are popular right now (and by comparison, no one listens to classical anymore so it therefore must be junk). Basically, it's a flawed argument.
Of course, none of that really helps you out because from the sound of your posts you're stuck with MySQL and won't have a choice to move to something else and I suspect that the detailed technically reasons aren't going to be as important to you as that fact. You might, for now, be able to drop in MariaDB as a replacement but that's only because it's a fork and is practically the same database (and for now very specifically tries to be 100% compatible). But give it time and it's likely the projects will drift apart enough that you won't be able to drop one in as a replacement for the other as easily as you'd like.
In short- a piece of software CAN be written to support multiple database backends, but the software has to be written specifically to do so. And if it is, it would have configuration options to select which database to use. If it doesn't, then it probably can't. And that will be true regardless of what the backend database is.