At 12:00 PM 28-08-02 +0200, you wrote:

>Alan,
>
>
> > I might jump in here...
> > I do not use foreign keys at all in my databases!
> > ooooh I hear frowns and tisk tisks here....
>
>You should have seen my face now - lots of frowns :)
>
>It's logically incorrect NOT to use foreign keys (or other measures of
>integrity) - this is what your DBMS is designed to do.
>
>So if it gives poor performance when you are doing this, it's because of
>implementation errors (or at least, not the best implementation possible).
>
>Hence, I would rather have someone taking a stand here and sponsor
>(money!!) the Firebird project to think of ways to do a better
>implementation for FK-related issues with poor selectivity. This way,
>one could still use FKs AND have decent performance.
>
>Triggers for integrity ... ouch.

I'll add my 2c to Martijn's and agree fulsomely. Cascading referential
integrity is the greatest thing since the breadknife. It's just an
unfortunate wart that we have to avoid it in the case of control tables,
because of its need to form bad indexes.
*Do* automated ref integrity wherever you can and, where you can't, do it
manually.

My tip is - do your formal ref integrity constraints late in development so
that you don't waste valuable development time unravelling other structural
mistakes. It's no big deal to keep two (at least) versions of your dev.
database in parallel.

heLen