cmbrannon79 at gmail.com
Fri Oct 23 22:33:24 EDT 2009
> > I prefer it to MySQL for several reasons. Please do investigate both, if
> > you haven't already done so.
> Would you mind telling us what those are? I might be about to take on a
> big database project myself.
I had to check the documentation,
because it's been almost half a decade since I've seriously looked at MySQL.
Most of my biggest complaints aren't quite valid anymore.
For a long time, MySQL didn't support foreign key constraints. It
accepted the syntax, but it wouldn't check them. In other words, using
FOREIGN KEY in a CREATE TABLE statement was a no-op.
One of MySQL's several storage engines, InnoDB, does support foreign key
constraints. It has done so for a few years now. The other storage
engines do not. You probably want to use InnoDB. Also, some of the engines
don't support transactions. Thankfully, InnoDB does.
Prior to version 5.0, MySQL didn't have stored procedures.
All of these things have always just worked out of the box for me with
Be careful about identifiers when using MySQL. Table
names are case-sensitive on Unix and case-insensitive on Windows. Trigger
names are case sensitive. Et cetera.
There's a MySQL variable called "lower_case_table_names". When set to 1,
table names are stored on disk in lowercase. Comparisons convert both operands
to lowercase as well.
You get the benefit of case-insensitivity, but it is not case-preserving.
The reference manual has the gory details.
That is a fair explanation of what I omitted earlier today.
Hope it helps.
More information about the Speakup