Slashdot Mirror
MySQL's Creator On Why the Future Belongs To MariaDB
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."
Arch Linux also made the switch three days ago: https://www.archlinux.org/news/mariadb-replaces-mysql-in-repositories/
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.
http://monty-says.blogspot.co.uk/2009/12/help-saving-mysql.html
http://monty-says.blogspot.co.uk/2009/12/help-keep-internet-free.html
http://monty-says.blogspot.co.uk/2009/10/importance-of-license-model-of-mysql-or.html
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.
Both support views and stored procedures and have since version 5.
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 of that whole issue was when you look at how the US pressured the EU court to approve the merger unconditionally.
It's mainly a problem for Linux distributors: they stopped providing things like regression tests and security advisories. Source: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-February/024478.html
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.
MySQL AB could dual-license MySQL because they owned the copyright on the code (outside contributors had to assign their copyrights over). Oracle owns the MySQL copyrights now. MariaDB, as a fork of the GPL code, is only available with a GPL license. He can't relicense it.
Do you even lift?
These aren't the 'roids you're looking for.
Michael Widenius has two daughters, My and Maria.
http://en.wikipedia.org/wiki/Michael_Widenius
ayottesoftware.com
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.
Don't blame me, I voted for Kodos
Actually MariaDB and Percona both support XtraDB which is a transactional backend that's a drop in replacement for InnoDB. MariaDB also supports the new Aria storage engine which can be both transactional and non-transactional depending on your needs (determined by option in Create Table statement).
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
It's a MySQL problem. Postgres is SQL standards compliant, MySQL isn't.
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.
Oracle don't want you to install it. They want you to employ an expensive consultant who knows how to install it.
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.
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.