For all of you that may not have direct web access (firewall'd etc.) and
because
everybody needs a good laugh, here is that excerpt from the mySQL page:

5.4.5 Foreign Keys
Note that foreign keys in SQL are not used to join tables, but are used
mostly for checking referential integrity. If you want to get results from
multiple tables from a SELECT statement, you do this by joining tables!
SELECT * from table1,table2 where table1.id = table2.id;
See section 7.17 JOIN syntax. See section 9.3.5 Using foreign keys.
The FOREIGN KEY syntax in MySQL exists only for compatibility with other
SQL vendors' CREATE TABLE commands; it doesn't do anything. The FOREIGN KEY
syntax without ON DELETE ... is mostly used for documentation purposes.
Some ODBC applications may use this to produce automatic WHERE clauses, but
this is usually easy to override. FOREIGN KEY is sometimes used as a
constraint check, but this check is unnecessary in practice if rows are
inserted into the tables in the right order. MySQL only supports these
clauses because some applications require them to exist (regardless of
whether or not they work!).
In MySQL, you can work around the problem of ON DELETE ... not being
implemented by adding the appropriate DELETE statement to an application
when you delete records from a table that has a foreign key. In practice
this is as quick (in some cases quicker) and much more portable than using
foreign keys.
In the near future we will extend the FOREIGN KEY implementation so that at
least the information will be saved in the table specification file and may
be retrieved by mysqldump and ODBC.
5.4.5.1 Reasons NOT to use foreign keys
There are so many problems with FOREIGN KEYs that we don't know where to
start:
· Foreign keys make life very complicated, because the foreign key
definitions must be stored in a database and implementing them would
destroy the whole ``nice approach'' of using files that can be moved,
copied and removed.
· The speed impact is terrible for INSERT and UPDATE statements, and
in this case almost all FOREIGN KEY checks are useless because you usually
insert records in the right tables in the right order, anyway.
· There is also a need to hold locks on many more tables when
updating one table, because the side effects can cascade through the entire
database. It's MUCH faster to delete records from one table first and
subsequently delete them from the other tables.
· You can no longer restore a table by doing a full delete from the
table and then restoring all records (from a new source or from a backup).
· If you have foreign keys you can't dump and restore tables unless
you do so in a very specific order.
· It's very easy to do ``allowed'' circular definitions that make the
tables impossible to recreate each table with a single create statement,
even if the definition works and is usable.
The only nice aspect of FOREIGN KEY is that it gives ODBC and some other
client programs the ability to see how a table is connected and to use this
to show connection diagrams and to help in building applicatons.

>David J N Begley wrote:
> >
> > The biggest problem I've encountered with MySQL for anything beyond
> very basic
> > databases is the lack of foreign keys, and the developers' incredible
> excuse
> > for their absence (other problems too, but this one beat all else):
> >
> >
> http://www.mysql.com/documentation/mysql/bychapter/manual_Compatibility.html#Missing_Foreign_Keys
> >
>
>Thanks for that link. It gave me a good chuckle. It really makes you wonder if
>the developers actually know much about relational databases.
>
>Paul
>--
>
>Paul Reeves
>Fleet River Software