I don't enjoy being a PITA but could you teach your MUA to create
proper attributions? This makes it really hard to tell who said
what, leads to confusion, and may piss of quite a few people if a
debate gets somewhat heated...
# [EMAIL PROTECTED] / 2003-04-02 18:18:17 +0200:
> > # [EMAIL PROTECTED] / 2003-04-02 17:37:26 +0200:
> > > And from this page:
> > > http://www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html
> > > I understand it is rather recommended NOT to use foreign keys, at
> > > least until mysql integrates it more fully.
> >
> > which part of that page makes you say that?
>
> I mean, at least that's how I reacted upon reading..
> "
> For MyISAM tables, you can work around the lack of ON DELETE 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.
> "
That doesn't say "we do not recommend using FKs with MySQL". It says
"FKs don't work with MyISAM tables".
> and
> "
> A properly written application will make sure internally that it is not
> violating referential integrity constraints before proceding with a
> query. Thus, additional checks on the database level will only slow down
> performance for such an application.
> It is not uncommon for a DBA to make such a complex topology of
> relations that it becomes very difficult, and in some cases impossible,
> to back up or restore individual tables.
> "
I read this: "an excuse for not having implemented FKs".
Yes, FK checks will slower the queries in the server, but you have
to do it in the client, so what have you gained? Plus, if you have
more than one interface to the database, you have to reimplement the
integrity checks over and over, which is error-prone.
And yes, I've seen a large database application (on Sybase; there
was only one client written) in which the programmers decided to
*not* use FKs because the checks brought the ASE to its knees.
> and I've got the feeling that the only advantage is that I could delete
> all related rows in tables that have the foreign key in one query
> instead of three or more(take the foreignkey values, delete the row,
> delete the rows in the related tables one by one..)
that's not the only advantage, although the MySQL authors probably
wouldn't mind if you didn't expect more from your life. :)
> That is an interestesting point because each time I have to code that
> in an application, it's error prone and it's not exciting.
Exactly.
--
FreeBSD 4.8-RC
6:55PM up 9 days, 9:15, 20 users, load averages: 0.04, 0.03, 0.04
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
