At 10:25 AM 21/10/2003 +0200, you wrote:

>Well the problem is that I have a few (5 or 6) small tables with few
>values. From what I understand from Helen, this means that the index
>selectivity is low, and hence that there will be a substantial performance
>degradation. Here comments on my original foreign key structure left me in
>no doubt whatsoever that it was a VERY BAD IDEA. :-D

It's still a VERY BAD IDEA to put referential constraints referencing your
low-count lookup tables. Lots of good things have happened to optimizer -
great, great things - but this isn't an optimizer problem. It has to do
with the index trees that are built for these indexes and the resulting
enormous delays.

>Inserts are no problem - much of it is already handled client side. Its'
>deletions and Updates that I can't figure out.

Can you explain the behaviour you want? writing your own referential
triggers is a piece of cake.

Actually, for stable lookup tables, my argument is that, if you design them
properly, you will never delete or update a key and so there is no
referential integrity to protect, no need for any foreign keys at all for
lookups.

The trick is - always key them with an atomic, surrogate key. Then you can
mess around with the lookup data to your heart's content and break nothing.

Helen