At 11:13 AM 27/11/2003 +0000, you wrote:

>I agree with this entirely but... there was some discussion a year or
>two back that FK's with low selectivity could affect performance (FB1)
>and that this would not be an issue if the creation of an index on FK's
>was made optional. In the meantime it was recommended (by Helen IIRC)
>that in this situation it might be preferable to implement RI through
>triggers rather than FK constraints.
>
>Is this still recommended with FB1 - or have I misunderstood the advice?

No, you haven't misunderstood the advice. These low-density lookup tables
are generally static and custom RI triggers work just fine. We seem to
have observed quite a bit of misunderstanding and scare-mongering in this
list recently wrt RI in general.

For example, in the latest posting from Jerome Bouvattier, he seems to be
referring to custom RI as "RI triggers". To me, the term "RI triggers"
refers to the system-created triggers that support declarative RI. In the
preceding thread, the whole question got confounded by mis-terminology...

I have, quite simply, never encountered compromised data integrity stemming
from either declarative RI *or* properly tested custom RI triggers. By far
the most common cause of compromised data integrity in my experience is bad
key implementations - typically where the db designer has blindly used the
output of a CASE tool as the database schema and the dependencies in a
database are made vulnerable to bad spelling.

heLen