I wrote

> >This is a very interesting point! I have often this kind of indexes
> >with a lot of duplicate caused by indexes of a foreign key. For
> >example value stores for code fields: Then I have perhaps 10 code
> >values used for some thousands of recods. Something like
> >
> >Table Data(
> > DataID Numeric (18,0),
> > CodeID Numeric (18,0),
> > Field1 ...
> > Primary Key (DataID),
> > Foreign Key CodeID REFERENCES Code(CodeID));
> >
> >Is it somehow possible to define such a compound index for foreign

key

> >fields? Or do you know another design solution for such a problem?
>

Helen wrote:

> Well, it's a design solution I use.
>
> I never use low-selectivity columns as foreign keys - I code the

cascades

> by hand in triggers.
> I DO create composite indexes (code + uniqueID usually, in that

order).

That sounds really like a good solution - even it's a bit time
consuming to realise it.
It would be easier if there is an extended foreign key syntax which
let me choose the index I use. But that's already an old discussion
(IB-Architect: Rebuilding foreign keys system indexes) and is
hopefully one of the extensions of FB 2.0 / IB 7.0.

Thank you for helping me!

Daniel Achermann