--- In firebird-support@yahoogroups.com, Tim Ledgerwood <tim@s...>
wrote:

> I have deleted all the FK restraints, except where I am fairly sure

that

> there will be high selectivity. For example, the addresses table

references

> the accounts table. Each is expected to have many entries, but there

is

> either a small subset of "addresses" for each account, or exactly

one.

> There is always exactly one account for each address.
>
> Am I on the right path here?

Tim, partly. Helen saw you ACCOUNTTYPETABLE is directory-kind static
table which records never be updated or deleted, in this
circuimstances advice is legal. On concurrently modified tables it is
not recommended to maintain reference integrity using non-system
triggers, queries in them works in context of transaction which modify
records and there are conditions when this transaction can't see
changes in referenced tables. Index-based FK which check only
existance works out of transaction context in most pessismistic mode
to protect your data. Usually such a reference don't contain many
duplicates because of nature of data (accounts - positions of accounts
for example, usually 5-10 positions for each header). But if
tables are not constant and we need reference integrity and one of the
tables is very short, we should use FK in spite of it's low
selectivity taking measures optimizer don't use it in queries.

Best regards,
Alexander.