[Discuss] Rob Conery's critique of MySQL?

[markw at mohawksoft.com (Mark Woodward)]

On 07/30/2012 05:28 PM, Derek Atkins wrote:
> Mark Woodward <markw at mohawksoft.com> writes:
>
>> That being said, my personal opinion is that *anyone* who chooses
>> MySQL without a clear and present "Only MySQL will with our apps"
>> requirement, is not much of a DBA and a terrible engineer.
> This sounds like a relugious argument, not a technical argument.
> Replace "MySQL" with "Python", or "Shell" above and it can read just as
> vitriolic.
Well, all this depends upon what is being compared and how. If the 
prices were the same, which would you prefer? A Fiat or a Mercedes?

In an argument of actual merit, MySQL does not hold a candle to 
PostgreSQL. Facts are facts. I'm not saying that you can't accomplish a 
job with MySQL, I mean, people do drive Fiats quite frequently with 
success, but it is inarguable that a Mercedes is a better car. Just as 
MySQL is very much inferior to PostgreSQL. The video is a good primmer 
and start at understanding *why* MySQL is bad.
>> I've been using PostgreSQL for over 15 years and it is one of those
>> tools that I keep in my belt because it is just amazing at how easy it
>> makes otherwise difficult tasks. Every year it keeps getting better. I
>> have been on far too many projects where some guy chooses MySQL
>> because everyone else does and stuff that would be trivial in
>> PostgreSQL are a nightmare.  On the flip side, I have yet to see
>> something that would be easy with MySQL that isn't equally as easy
>> using PostgreSQL.
> And I have the inverse.  I've been using MySQL for over 10 years, I'm
> comfortable with it.  The one or two times I had to interact with PG I
> had no idea what it was doing or how to talk to it.  IIRC I couldn't
> even figure out how to get it to simply give me the list of tables in a
> database, let alone quit out of the client!  With MySQL it's a simple
> "explain <table>;".
Well, sorry if I am harsh, but ignorance of a tool is not the tool's 
fault. Blaming PostgreSQL because it is not MySQL is like blaming 
Mercedes because it isn't a Fiat.  PostgreSQL is actually more compliant 
to SQL standard than MySQL.

>   I'm sure PG has some way to do it, and *ONCE YOU
> KNOW IT* it's simple.  However once you've spent 10, 15 years with a
> tool then you don't want to spend another 10-15 years learning another
> tool just to get as comfortable as you are now.
It isn't about "comfort" it is about functionality. I will learn the 
tool that can best do the job. MySQL, quite simply, is a bad database 
for many many reasons.

>> As I tell my son, "You have to own your opinions. Merely accepting
>> someone else's opinion isn't good enough. Believe what you want, but
>> make sure you understand what you believe and why."
> Sure, and there's a lot to be said for using tools with which you are
> comfortable.
NO! Comfort is no reason to choose a database. Unless you do not care 
about a product life cycle, you choose the tools and infrastructure 
based on merit. Every component in a project has to earn its place.
>
> Like everything, it's a tool.
Yes, both MySQL and PostgreSQL are free, so the *only* debate is about 
functionality, including accuracy and performance, as well as storage 
and administration. On the grounds of merit, MySQL can not win.

>   The key is using the right tool for the
> job.
I hear that sorry line for MySQL proponents a lot. What qualifies 
something as the "right tool?" Both are free. Should not the "right 
tool" be the one with the highest merit?

> Just because you need an RDBMS does NOT imply that PG is *the*
> right tool.  It is *a* right tool.
Absolutely not. I've been doing database work in my career since dBase, 
I have used a *lot* of databases: db2, advanced revelation, sybase, 
oracle, mysql, msql, postres, sqlite2&3, mssql, a slew of xbase systems, 
and a lot of system that I don't really consider databases like Berkeley 
db, and a whole lot I don't even remember.

When you want a database, you want a tool to organize, store, and query 
your data. Presumably within some economical representation and with 
performance. Then you do the engineering involved, compare the various 
"tools" available and weigh the pros and cons, including price, by the 
way, and if you are intellectually honest, MySQL won't measure up.

If you say you don't need transactions, that is because you don't 
understand transactions.
if you say multi-version concurrency isn't important, that is because 
you don't understand what it is, and why you need it.

The hard part of this discussion is that the important features of 
PostgreSQL that MySQL lacks are there for very good reasons. PostgreSQL 
makes doing the hard stuff of a data centric application less hard.
>
> There are other choices, and those other choices *are* valid.  It all depends on the requirements.
I'm not an "all opinions are valid" type of guy. I don't like technical 
discussions were "opinions" and "preferences" weight the same as facts. 
Give me a list of technical requirements for a database for a real life 
project (not "facebook" thank you very much) , and I'll explain why 
PostgreSQL is the better choice for almost every requirement. It is my 
assertion that PostgreSQL will be a better choice based on the criteria 
you present.

> Without knowing the requirements all other
> discussion is purely rhetorical or religious, neither of which belong on
> a technical list.
Not really, not at all. If you need a database, you wish to solve a 
certain set of problems. In the history of computers, databases are one 
of the most well understood tools. It is easy to evaluate a system based 
on the merits of its genre.

>
> -derek
>