5 ms·

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

by amix 13y ago

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!

davidw 13y ago
> 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.
- amix 13y ago
  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.
  - smoyer 13y ago
    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-making-mysql-scale/ http://gigaom.com/2011/12/06/facebook-shares-some-secrets-on...
smoyer 13y ago
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.
- mercurial 13y ago
  Besides, the assumption that only a single application will access the database is often wrong in the real world.
lucian1900 13y ago
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.
- regularfry 13y ago
  MySQL replication is the one place it's got the edge.
- ingrownpsyche 13y ago
  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.
  - jfb 13y ago
    The advantages were ease of installation on Windows, and network effects.
- amix 13y ago
  Postgres got proper non-hackable replication in version 9... And it still isn't that great.
  - asdasf 13y ago
    "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.
asdasf 13y ago
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
- fleitz 13y ago
  You forgot silent data loss.

by amix 13y ago

davidw 13y ago

> 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.

amix 13y ago
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.
- smoyer 13y ago
  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-making-mysql-scale/ http://gigaom.com/2011/12/06/facebook-shares-some-secrets-on...

smoyer 13y ago

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.

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

lucian1900 13y ago

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.

regularfry 13y ago
MySQL replication is the one place it's got the edge.
ingrownpsyche 13y ago
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.
- jfb 13y ago
  The advantages were ease of installation on Windows, and network effects.
amix 13y ago
Postgres got proper non-hackable replication in version 9... And it still isn't that great.
- asdasf 13y ago
  "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.

asdasf 13y ago

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

fleitz 13y ago
You forgot silent data loss.