There is literally zero appropriate use cases for mysql. If you need a relational database, use one. If you need a network hash table, use one. Don't use mysql at all.
I agree. There is no proof that MySQL cannot do the job when configured correctly. Furthermore, another issue is with coding. Sometimes unnecessary nested "if" statements can cause huge problems no matter what type of database you use.
>MySQL is a high performing, highly scalable, ACID compliant relational database, when configured correctly.
You forgot the "with tons of brokenness, misfeatures, mistakes, problems and otherwise NOTABUG bugs that will never be fixed and cause immense amounts of pain". Literally every other RDBMS is a better option, thus there is no reason to use mysql.
Simply repeating anti-MySQL rhetoric is not going to convince anybody that it has actual problems, just that you've had bad experiences in the past that have biased you strongly against it.
It's particularly not going to convince people when it's so widely used (from Wordpress installations to Facebook), and perhaps more importantly when it's offered as part of the two largest VPS providers.
On topic, I'd be happy to offer some advice on how to set up MySQL in a way that limits (or eliminates) the concerns proffered by most "MySQL is not Production Ready" comments... the two most oft cited problems being sorted by the following two my.cnf settings:
You can avoid buffer overflows in C by using a library that's got safe strings.
Does that make C safe? Nope.
The Windows NT architecture has an enormously rich security mechanism that can allow arbitrarily granular security statements to be made about almost everything. But the default policy until Windows 7 was "pretend you're Windows 95".
Did that make Windows more secure than Unix? Nope.
I don't like rhetoric either. I think it is good to consider the facts, and for me generally the situation/environment/problem as much as possible.
I like to consider the problem, before I recommend a solution generally ( I don't mean to accuse you of pushing a solution, I think you are offering help which is always appreciated ), but I think a lot of people are used to having had the choice already made ( and indeed, in some circumstances it is!).
One thing I always try to remember about mysql, as it is is less than intuitive to me, at least that there is no way I am aware of to alter or restrict this behavior directly, is that in mysql the client is allowed to alter the sql-mode ( I do think I have used proxies to filter out this behavior as a sort of guardian, but that was not an ideal fix by any means ), generally if you don't have control of your clients ( or also hopefully some good layers in front ) in the RDBMS world you are already sunk, but this has been more as a guard against accidental breakage for instance.
This can make it unsuitable for certain situations ( where you may not have control of the client ).
One thing that I think is both a strength, and a weakness ( again depending upon the situation ) is that mysql is very flexible and can be deployed in so many different configurations.
Generally I think it is best for people to carefully consider their situation and needs ( and be prepared to change when the situation does!).
I really enjoy working with Postgresql as well, and have long respected the code produced by that project.
In summary, I'd say there are many great databases ( both relational and otherwise!) which can be a real asset to solving problems. The best thing I think is to learn directly and continually :)
>On topic, I'd be happy to offer some advice on how to set up MySQL in a way that limits (or eliminates) the concerns proffered by most "MySQL is not Production Ready" comments
There are no settings for "make triggers actually work", or "remove arbitrary limitations like being unable to update a table referenced in a subquery", or "make views with aggregates perform well enough to be used", or to add expression indexes or check constraints or window functions or let you set defaults to functions or to have a transactional DDL or to make rollbacks not corrupt the database or to allow prepare/execute in procedures or to allow recursion in procedures or to allow triggers to modify the table they were fired against. That's the point, mysql is full of crippling limitations. There are non-broken databases available that are superior in every single way. Thus there is no reason to use mysql. I know quite a lot more about mysql than you seem to think I do, and there is a reason that the only thing I do with mysql is conversions from mysql to an appropriate database that actually works.
Reason to use MySQL: It's easy to find people comfortable with it that won't accidentally shoot off a toe doing simple things.
The "Don't use MySQL" argument smells like the "don't use bcrypt" argument to me. You're letting the perfect be the enemy of the good, for 95% of the usecases where you're doing something dumb like using MongoDB or homebrewing something, MySQL is a better choice--even if it isn't often the best choice.
I've never seen a single mysql database where there was no toe shooting happening. People just don't seem to miss their toes. In 100% of the cases where you used mysql, postgresql was a better option in every way. It isn't letting perfect be the enemy of good, it is saying "don't use bad software when there's good software available".
