Hacker News Reader

Comment by amix | Hacker News Reader

MySQL was a great database that solved a problem. It did not solve it in a 100% complaint way, it did not have all the features that "dbms experts wanted", but in the early days it was very easy to started. In version 5+ they have fixed a lot of the issues and it is now on-par (or better) than most other databases. I also think they have focused on the right stuff: ease of use, easy way to fix performance issues, great ways to setup replication, great ways to take backups, not losing data, optimized to be used for the web etc. Also, most bigger properties (including Facebook and Google) use extensively MySQL.

If Mongo is going to be like MySQL, then great!

View on HN

> but in the early days it was very easy to started

It's easy to start a bicycle rolling down a steep hill too. It's only later that you find out whether the brakes, tires and handling characteristics are up to par...

> features that "dbms experts wanted"

Maybe they want those features because the know what they're doing, and think some of those features are pretty critical.

And you base this on what? MySQL is used to scale some of the biggest Internet properties in the world and it has been doing that for many years. Stop spreading FUD.

FUD is actually useful (engineering FUD rather than marketing FUD) ... if you pick MySQL because it's easy to get started, you need to know its pros and cons. Those scaling MySQL at the biggest Internet properties in the world ARE database experts - Facebook for instance has a custom cache and memcached in front of their MySQL instances [1], shards their data and also uses other database technologies where appropriate. People like Facebook’s Mark Callaghan will be successful using any reasonable database.

[1] - http://gigaom.com/2011/12/06/facebook-shares-some-secrets-on...

If "is now on-par (or better)" means usable then I'll agree. I'll also agree that you don't have to be an expert to use it. Sometimes having expertise is useful.

Prior to version 5+, I'd have called it unusable as the lack of real foreign key constraints (for instance) was simply unacceptable for real applications. The argument (by NoSQL proponents too) that the application has to check data constraints anyway might be true, but ending up with dirty data is the worst possible outcome. Check it in both the application and the database if you can.

Besides, the assumption that only a single application will access the database is often wrong in the real world.

MySQL still isn't on par or better than its most comparable peer, Postgres. It's still nowhere near as terrible as Mongo, but let's not pretend it's amazing when it's merely serviceable.

MySQL replication is the one place it's got the edge.

Is it not the case that back in the day MySQL was better suited to running small to medium website backends with simple schemas out of the box? I know this hasn't been the case for a long time but I think it might be a contributing factor to MySQL's success.

The advantages were ease of installation on Windows, and network effects.

Postgres got proper non-hackable replication in version 9... And it still isn't that great.

"Isn't that great" how? In that it imposes a bunch of limitations on you? Or that it frequently breaks and slaves have to be manually syned? Oh wait no, I was thinking of mysql.

Have you ever used any other database? Literally every single thing you listed as being a plus of mysql is something postgresql and sql server both do better. Mysql is in no way even close to being on par with non-broken databases. A brief list of some obvious, glaring flaws with mysql that have been actual problems in practice:

no check constraints

views with aggregates are too slow to be used

no expression indexes

triggers don't fire on cascaded actions

no window functions

can't set default values to be the result of a function

no transactional DDL

doesn't have multiple databases, just schemas misnamed as databases

rollbacks are orders of magnitude slower than other RDBMS, and it is interrupted it can corrupt the database

functions can't use prepare/execute, so no dynamic SQL in functions

subqueries are broken: can't modify and select from the same table

functions can't be called recursively (seriously? is this 1962?)

triggers can't alter the table they are firing against

stored procedures can't be invoked from prepare/execute

"slow query" log has a completely useless resolution of seconds

You forgot silent data loss.

Reply on news.ycombinator.com