Re: [tlug] MySQL vs Oracle

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Ryan" == Ryan Shaw <ryan.shaw@example.com> writes:

    Ryan> But if this is a website, and not some sophisticated
    Ryan> financial app, speed rather than absolute guarantees against
    Ryan> data inconsistency is probably your main concern. In this
    Ryan> case MySQL (sans transactions) will blow away everything
    Ryan> else.

Potentially including your whole database, if you are doing updates.

It is true in general that with simple, almost-always-read DB designs
and fast hardware, you will rarely have a problem, and those few will
be localized to a row or three.  You can go years without detecting
any corruption, and none of your friends will see any, either.  Then
you change the design, or add user updates ....  Can you really ever
afford to have catastrophic data loss?  Are you really sure it
wouldn't be cheaper to double the number of CPUs you throw at the
problem?

Unlike the question of whether to back up a RAID storage device where
you can get (at least in theory) reliable data on MTBF and multiply,
deciding how risky a particular database design is is hard (even
harder than the Bash manual!)---and the people who can do that are off
implementing transactions.  They're doing that because in the long run
it's cheaper to have ACID in the RDBMS than it is to do the analysis
for every database design.

And you can generally tune more full-featured RDBMSes to not do some
of the checking that they do by default, getting significant
performance increases.  

It seems to me that the real reason for the popularity of MySQL is
that it is perceptibly faster, _especially in the prototyping stage_
(before DB resource contention becomes an issue), and the features
that you sacrifice also come at a significant cost in complexity of
user interface and administration.  Ie, MySQL is a great way to get
started, especially since it has bindings in every CGI language known
to man.

None of this means that there aren't situations where MySQL isn't the
perfect tool.  After all, I chose my RDBMS for a _really_ frivolous
reason: XEmacs links to libpq.  ;-)  But I'd think twice before
deploying MySQL for any data that could make me money if it didn't go
away, where I don't control the rate of access (eg, precisely the
webapps that MySQL is so popular for!).  I might use MySQL anyway, of
course.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py