NYCPHP Meetup

[David Sklar]

> David,
>
> MySQL lacks in quite a few areas.
>
> 1) It has poor performance under heavy loads
> 2) It lacks key functionality
> 3) Data integrity is currently a big problem
> 4) Large amounts of data are handled poorly
> 5) It lacks replication and other enterprise level features
> 6) Backup and recovery features could use improvement
>
> Just use MySQL for a while and try to do anything like a join on more
> than two tables.  It chokes.  Other databases are built to handle real
> and heavy processing, whereas MySQL is built for smaller needs.

We can debate what "heavy loads" means, and Ophir's earlier comment about a
few thousand simultaneous connects may be a good example of an area where
MySQL has problems. In general, though, I don't agree with much of your
assessment above.

The only "key" piece of functionality that I've heard people complain about
recently is sub-selects. If your application requires sub-selects, then yes,
MySQL isn't the database for you.

The InnoDB engine offers excellent transaction support, foreign keys, and
data recovery. If you want, you can even pay $400 for a hot-backup utility
that lets you setup MySQL replication slaves with no downtime for failover.

What's a "large amount" of data? I've succesfully used MySQL with gigabytes
of data in tables that have millions of rows. With multi-table joins. What
were you doing that ran into problems? Having appropriate hardware and
configuration is important for success.

Again, I make no claim that MySQL is perfect. It has no stored procedures,
for example. But if you're going to knock something (be it MySQL, Oracle, or
Berkeley DB), provide some specifics. Maybe you tried to use MySQL and
Oracle on similar hardware and Oracle provided better performance? Maybe
Oracle is easier to tune for a particular situation that MySQL? Maybe even
(and this is IMHO a perfectly justifiable reason to pick a technology) you
or your company has more in-house Oracle knowledge than MySQL?

What has drawn me into this thread, however, is criticisms like "It lacks
replication and other enterprise level features". This obviously false --
search on Google for "mysql replication" and the first link that pops up is
to the section of the MySQL manual about Replication.

> Some
> will argue the de-normalizing data is always the way to go anyway, but
> unless you are data warehousing there is no need to do it.  It just
> creates poor database design.  You might be able to get away with using
> MySQL on some heavier projects, but that doesn't make it the right tool
> for the job.

I'm a big fan of normalized data.

> As for your enterprise question, I classify enterprise
> level as an application (this is not limited to web applications) that
> is currently or possibly going to be under heavy load and needs to be
> distributed over multiple machines effectively.  The application needs
> to be scalable to decrease the risk of poor application performance with
> increasing loads.  As I said this is often misclassified because people
> throw the word around without cause.  Most applications don't have
> enterprise needs, which makes PHP a great choice for development.

What prevents PHP from being scaled across multiple machines and across
machines of increasing strength to accomodate application load growth?

-dave