I was just reading this post on ars technica "Is MySQL really this bad?" and was really surprised most people seem to agree that MySQL is indeed bad.
I was just curious, does it really matter for most applications? Should everyone stop using MySQL? I'd really like to hear from people that have worked with various databases.
For large and complicated systems, yes, there are enough bugs / quirks that can rear their ugly heads - I am convinced that the reason that people tend to always go with MySQL over PostgreSQL is that the name "MySQL" is much more attractive.
Why PostgreSQL chose to throw up a barrier on even being able to pronounce their name I will never know - an entire section of the PostgreSQL wikipedia page is dedicated to PostgreSQL's name.
If you have read the article you post, you would understand that it shouldn't be avoided all the time. It's on specific task that other database system might work best.
The article specifies problems with :
If you do not do these type of operation, than MySql is fine. I am using PostGres and MySql... I think MySql get that much popular because it's available on many hosting provider and not PostGres. But, I have no problem using MySql when needed. I might not choose it if I have all options but it's for sure not a bad product...
Wikipedia (seventh most popular website in the world; has over two million articles and over 15 million pages in total) is built on MySQL. That's good enough for me :)
There are two extremes where you'll find disgruntled users:
Lots of people experience MySQL through their hosting provider. Those on the cheaper hosting tend to be crammed onto massively oversold, underpowered hardware and as a result have bad experiences.
Then there are the people who need massive systems with complicated failovers and replication going on. MySQL can scale, but it's neither pretty or simple.
It's the DB of choice for most because it's been around forever and it has plenty of tools for poking it. In time, unless Sun do something with it, it'll be replaced by PostgreSQL or a newer DB tech.
It depends really what you expect. Most of these problems are not really bugs with MySQL, but the way it has always worked (retaining backwards compatibility) - the way it is documented to work.
Some of the issues the author has problems with can be fixed by using MySQL 5.0's strict mode - however, you don't want to do this if you're using a legacy application not built to work with strict mode, as you'll get errors that your application does not expect.
People do not complain about the things that they do not use.
I've used MySQL and still use Oracle, and MySQL is as bad as they make it out to be. Does that mean no one should use it? I don't think so.
We had a number of applications that were tiny (one or two tables, no more than 50k rows), and instead of using Oracle (which, at the time wasn't allowed due to licensing) we developed on MySQL. For all the reasons laid out in the forum thread: free, easy to install, easy to manage, free, not a lot of overhead.
Now this was back in the 3.23.x days when things like InnoDB or FKs or any of the other stuff was non-existent. And for what we needed it worked perfectly. It took inserts, updates, etc. with ease, never corrupted, recovered nicely off tape, everything.
But then the apps that it ran under didn't need an Oracle or a SQL Server to run. All I had to do was (as any good programmer should) was to validate my input, make sure I'm using transactions as needed (at the app level, not at MySQL because in those days it wasn't ACID compliant), and that was pretty much it.
The best part is, one app in particular was written in 2002. Last I checked, it's still running 6 years later, still on MySQL (I think it's 4.1 now or something) and still doing exactly what it was written to do.
So, yes, it sucks for e-commerce, banking, or data warehousing of any great variety (tried that too). But if you need a quick Recipe Box application, or some other twiddly little app, then MySQL will work just fine.
My sense is that MySQL is leaving it's roots as a dead-simple, fast little DBMS in favor of triggers, constraints, FKs, etc. I think that's where the suck of MySQL comes in to play. If your DB requirements are simple, MySQL will work 10 times out of 10. At least that's been my experience.
MySQL focuses on speed and scaling-out with commodity hardware. Other RDBMS brands focus on different feature sets, such as stability and standards. You should read this interesting comparison between postgresSQL and MySQL that really expands on the important differences.
MySQL has its usage, and as a satisfied customer I have only (mostly?) good things to say about it.
Most of MySQL's problems are down to its configuration. You can tell it to be strict with invalid input, or tell it to use a storage engine with foreign keys, but the reason it gets a bad reputation is that it's extremely lax by default.
On the other hand that default setup with few checks means it's fast. In some cases the speed is worth more than data integrity, and there's nothing wrong with that if it's used in the right place.
MySQL is free, fast, easy to install, and works for simple applications. That's the legacy of MySQL, and why it became popular.
MySQL has been growing beyond its "little database engine that could" origins, trying very hard to crash the traditional high-scale RDBMS market, and take on the dominant trio of Oracle, MS SQL Server, and IBM DB2. So the market is now more likely to compare MySQL to the "big boys," instead of to other upstart projects. MySQL's foibles naturally seem less forgivable in this light.
PostgreSQL was long considered the primary competitor to MySQL, since both are open-source. PostgreSQL is arguably a superior implementation of SQL, but it has a steeper learning curve. It also failed to provide a native Win32 port for a couple of critical years during which MySQL established a lot of market share. PostgreSQL has never had the marketing effort behind it to make up that lost ground.
This issue with MySQL is that they started from the wrong place. Back in the day MySQL was really just a collection of indexed files that you could run an (elementary) SQL Engine against. It didn't have transactions, constraints, procedures, triggers, subqueries or virtually anything else that makes a real RDBMS a real database.
Even then it had fanboys, and whenever you brought this up with them their stock answers were (a) you should code all that stuff in the application logic anyway and (b) but look how blindingly fast it is (which it was, given that it wasn't really doing anything).
Just recently however MySQL has seen the light and grafted on much of the above. Conversations with the fanboys now generally run along the lines of 'but MySQL hs that too!' Now I'm sure that there's a great many bright coders working on MySQL, but as we all know programs which have features grafted on retrospectively instead of designed in from the ground up are more liable to errors, misfeatures and inconsistent behavior.
Which is what recieved wisdom tells us we have (ignoring the fanboys).
Personally I am much more inclined to use MySQL now than I was before version 5, and I'm sure that given the effort being put into it sometime around version 7 it may be completely trustworthy for mission-critical applications. In the meantime DB2, Oracle, MSSQL and Postgres are wiser choices for mission critical applications as these were all built as real RDBMS' from go and allow you to sleep soundly at night knowing your data is completely safe. MySQL is an excellent solution in areas one or two steps back from that.
I've worked with one application that could use any major DB: MSSQL, Oracle, MySQL, Informix, DB2, Sybase, etc.
From them all the most problematic to support was oracle. But in general all of them ( oracle included ) were very easy to work with, for the application used very simple SQL statements.
Should everyone stop using MySQL?
Well, it depends of what tool better suit your needs.
A lot of organizations choose one DB and they will to to the end of the world with it.
However one thing that is very interesting is that some of the most important companies in the internet uses it:
And they don't use it for the HR process, but for the core ( I'll try to get a quote for that )
In the mean time here is the list of customer MySQL has.
http://www.mysql.com/customers/#e-Commerce
Some others:
That was one of the reason for Sun to buy MySQL for almost 1 billion usd. Plus, this way Sun could compete against MS with MSSQL server + .net and Oracle + Weblogic
If you see they have both application servers and database, Sun lacked of DB and decided to buy it.
Of course not all companies are that big, and for some closed business MSSQL and Oracle are much welcome.
EDIT Argh... I cannot find the resources that state this clearly ( without having to read a lot of pages ) . The only one I found was on Wikipedia http://en.wikipedia.org/wiki/Wikipedia#Software_and_hardware
It works for my small, piddly, not-very-exciting projects that do not have many highly linked tables.
Lots of people swear by MySQL. Many of us just swear at it.
There's always the idea that you're not going to need some of the features offered by other database systems...but then one day you need them.
The most recent for me was check constraints. I really needed check constraints because people kept reversing longitude and latitude columns in my DB. I added the constraint in several places and then later discovered that it's just ignored. Caused lots of pain.
The other thing that's killed me is the exemption of so many things from transactions -- most notably schema modifications. Why can't I alter or rename tables and roll them back if I don't like what happened?
Here is my experiences. I was taught in college excel and then Access in a basic computer office class. Those were my "first databases". Now I can't scream enough "EXCEL IS NOT A DATABASE!!!" Later when I took a database class we were taught Mysql. So naturally when I got out into the real world I used what I knew.
I work for a web based company that uses mysql as it's primary DB, but close to a year ago we started working with GIS data and decided to use PostgreSQL for that information. I learned postgreSQL grudgingly, and have since come to like it, but at the same time it has helped me appreciate mysql even more.
My opinion is that MySQL is more of a programmers DBMS. Whereas postgreSQL, and others like it are Database Administrator's DBMS. As a programmer I love Mysql for:
I work at a company that didn't know what 1NF was when I got there. But the company is sucessful, and as a programmer I am satisfied with the DBMS choice.
I am afraid it is - I have been using it a lot and i wasn't happy with that
I'd just throw out there that a few intense-load sites like Digg use MySQL. I'm currently considering which is a better choice for my (PHP) application - MySQL (which I'm more familiar with) or PostgreSQL (which has less PHP support (no Object-Oriented wrapper) but seems tried and tested).
I have been using MySQL since around 2002 and have always enjoyed working with it. I remember early on in my programming career, people would write off MySQL as a toy database.
I understand all the arguments against using MySQL for large data warehouse projects. You wouldn't want to use it if you were building a massive credit card company application.
Having said that, for most things on the web, MySQL does the job just fine. If you have any doubts, just look at the Wikipedia which is built on top of MySQL and PHP.
This question is like the constant PHP questions: most of its "problems" aren't problems to most people who use it.
In an environment where you have one application that plays on the database -- like a website -- you'll find a lot of the issues about default values and referential integrity just Go Away because the application has to look after them anyway. So it does. And then it doesn't matter than the DB doesn't.
Just for kicks, PostGreSQL is percieved as being behind SQL in one very important area: replication. MySQL has replication built-in and it pretty much works. But it's not built-in to PostGreSQL: it's an add-on, requiring another level of setup and configuration. This is an unfortunate perception, but I've seen it completely halt a project that could have migrated to PostGreSQL.
Another list of reasons why MySQL is bad can be found at this excellent comparison versus PostgreSQL:
It's easy to rag on MySQL, but the grass is not necessarily greener with other databases. I use MySQL currently, and have used Oracle and MS SQL in the past, and although the details are fuzzy now, I remember many, many times finding bugs/features in both Oracle and MS SQL that made me think "people pay money for this?!?". Every database has loads of problems, but at least you don't have to pay money for the problems in MySQL...
The fact is that huge web sites like Digg, Facebook, Flickr, YouTube, Wikipedia, and many others run on MySQL. So how bad could it really be...?