MySQL RANT

[Tom Metro]

markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org wrote:
> I don't want to start a flame war but I got to get this off my chest.

We've discussed your MySQL aversion off list a while ago, and I can 
sympathize with some of your reasoning, but I wouldn't recommend others 
take the same approach of outright avoidance, so I'll add a few comments 
for the broader audience.


> It is both a technical decision and a form of protest.

I feel the same way about some of the P* languages in LAMP - I find that 
they range from poorly designed to being redundant with existing 
solutions - and while I'd not likely use one on a project I was 
developing, I don't oppose their use as a practical matter. The 
popularity of tools ebbs and flows over the years, and the reality is 
that if you want the widest choice of applications, you need to tolerate 
working with some components that you don't think are ideal.

Would you refuse to run an application because it happens to embed a 
version of GTK you don't like?


> I don't like the bogus benchmarks they use.

I've never picked MySQL from a menu of choices due to performance 
benchmarks, but if you feel strongly about this false advertising, you'd 
probably get across your point more effectively by occasionally posting 
messages on BLU pointing out specifically where the MySQL corporation 
has made false claims. I don't pay too much attention to what the MySQL 
corporation does or says, but it would be of interest to hear.


> I am a Linux user because I choose to be. This sometimes means not using
> some otherwise good programs that only on Windows because I choose not to
> run Windows.

There's an old computer adage that you choose the best applications 
first, then you chose the operating system and hardware to support those 
applications. Of course that degree of freedom isn't there in most cases.


> Almost every argument about using MySQL despite its suckage are the same
> arguments for using Windows. They are false and easily refuted.
> 
> If a program chooses to only use MySQL, I can only assume the developers
> are clueless about databases in general...

So how do you refute popularity? Ubiquity?

There are non-technical reasons for choosing a component. If you're 
starting a project with light database requirements and you want to 
maximize the number of potential developers that are familiar with your 
database and the number of machines that will already have your database 
installed, then MySQL is the right tool for the job.

You also have to consider how many UNIX applications evolve. Half of 
them start out as a collection of shell scripts. :-) Slowly evolved with 
various components rewritten in other languages. From this perspective, 
database selection is often about using whatever is handy, because it is 
already 10 times better than the flat files it replaced.

If you are the one running the project, you obviously can set your 
priorities differently. I sympathize with your frustration over a 
technically superior tool being passed over for a more popular tool, but 
if you want to see wider adoption of other databases, instead of 
refusing to use popular open source applications that use MySQL, you 
should consider leading an effort to port them to something better.


>Tom Metro wrote:
>> ...they want everything to run on Oracle,
>> even if that means performance will suffer.
> 
> There is no way performance would suffer by using Oracle instead of MySQL.
> MySQL only outperforms other databases on carefully constructed benchmarks
> in read-only situations or single user operations.

It was not "carefully constructed benchmarks" but instead a real-world 
application. However it was a web-based product, and like most products 
of that type, it was predominantly skewed towards read queries.

You're experiences may be different, but on the same hardware, most 
things about Oracle felt sluggish compared to MySQL - from installation, 
startup, to connections and queries. But Oracle does (or at least it 
used to - I haven't used Oracle since 2002) a lot more than MySQL, so it 
is justifiably more resource intensive, if you need it.


> I did a project for Yahoo...they said use MySQL. Never again. On a well
> tuned MySQL, one query took 12 minutes.
>
> Now, if you tell my that my properly constructed queries need to be
> rewritten to work with MySQL, I will tell you instead that MySQL is
> lacking basic SQL functionality.

And what year was that?

One of the dangers of being an old timer in this business is that you 
form impressions about tools when they are fairly new in the 
marketplace. As a result, the buggy, under featured versions are what 
establishes their reputation, and that can be a reputation hard to 
shake. (See the recent thread on software RAID.) The MySQL of today is 
substantially different from the 3.x product that existed in the early 
part of this decade.

If you find that MySQL is still "lacking basic SQL functionality" today, 
then clearly it isn't the right tool for the kinds of projects you are 
doing. Anyone who claims MySQL is a universal solution is foolish.

A better question is, would MythTV perform better if it used PostgreSQL? 
(If it does, then all the more reason to encourage porting.)


>> It's easy to treat MySQL as an embedded database...
> 
> SQLite already fills that gap.

Yes, but with SQLite you don't have the option of scaling up to a 
client-server model without porting your application to a different 
database.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.