Alexander Bokovoy wrote:

> I don't see any reason for enforcing foreign keys because of this quote
> from MySQL documentation:

Note that MySQL has been widely critisised as being 'NFS with an SQL
front-end' vs. being a 'real database'. I'd not take the sole word of
the MySQL team on what constitutes proper database design. MySQL is All
Good if you know what you're doing. It's fast, too. It isn't the best
database out there from a designers' point of view, though.

>  Disadvantages:
>      * Mistakes, that are easy to make in designing key
>        relations, can cause severe problems, for example,
>        circular rules, or the wrong combination of cascading
>        deletes.

Non-argument. It means that if you mis-design your database you'll get
bitten.

>      * A properly written application will make sure
>        internally that it is not violating referential
>        integrity constraints before proceding with a
>        query. Thus, additionaly checks on the database
>        level will only slow down performance for such
>        application.

Severely misguided "we don't support it so here's the benefit" argument.
The above means every separate application can have a different idea of
what it means to be referentially correct. If one of those apps
conflicts with others, oops. Essential relations should be enforced in
one place (one of the reasons for having the common scripting
middleware).

>      * 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
>        backup or restore individual tables.
> "

Loosely translated to "If you let and untrained architect design your
database, here's some more rope to hang yourself with".

I don't buy these arguments. It's easy enough to dismiss that which you
haven't (yet) implemented for whatever reason. I don't hear any Oracle
or PostgreSQL (etc) complaining about the restraints of using enforced
referential integrity checks. Good database design isn't necesarily
easy, and anything which makes it easier to go ahead while having major
flaws in your design (which is what they're outlining here) is an
inherently Bad Idea IMNSHO.

Emile



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to