[dijit]

To be perfectly fair with you, you can make bad choices and still get something useful done.

Most companies are not alive "because they chose mysql over something else" they're alive because they have "good enough" tech to get the job done. The job that they're trying to accomplish is the thing that makes them successful.

Uber isn't super huge because it used a specific database technology. It's huge because it's good at marketing, it's providing some value to people.

[otterley]

If it got the work done at a reasonable cost and performed reasonably well (i.e. it served the purpose it was meant to serve), how “bad” a choice could it have been?

[zeveb]

I'm reminded of an article about zombie companies I read recently: they're companies which are inefficient/pporly-managed/poorly-executing, but due to market/regulatory inefficiencies they're not dead yet. Companies which use MySQL are in a similar situation: they're not doing as well as they could be, and all other things being equal they ought to be put out of business by their competitors — but all other things are rarely equal.

Still, if you are making choices for yourself, you don't choose mediocrity and hope to muddle through: you choose excellence. Choosing MySQL isn't choosing excellence.

[otterley]

“Excellence” is a poor criterion for comparative analysis because it is (a) subjective and (b) unquantifiable.

Do you have objective or quantifiable data and references upon which your opinion is based, _and_ is universally applicable to any arbitrary problem that a SQL database might be an appropriate solution for?

[dijit]

If it costs development time because they need to be extra careful about not sending queries that ERROR and 'wipe' data.

If it silently corrupts data over years and gets discovered much later. (As was the case with my previous company, an e-commerce retailer that lost large chunks of order history)

[otterley]

Are those problems still unresolved in MySQL today? How do you know that similar or worse problems did not exist in alternative solutions at the time it was implemented?

[dijit]

MySQL is making strides to fix these kinds of issues ever since the Oracle acquisition for sure.

> How do you know that similar or worse problems did not exist in alternative solutions at the time it was implemented?

Because I've been working on database solutions for over 10 years, there are problems in other software but I consider data loss to be worse than any of them. For example the autovacuum in postgresql 8.3 and before was mostly garbage which ended up bloating highly transactional databases. But deleting data when you fail a constraint is worse.