> Jim Starkey <jas@...> wrote:
>
> There are two problems associated with enforcing referential
> integrity. The first is whether or not the system should
> create an index on the foreign key. If the system guesses
> wrong (and it has very little to go on), and either creates
> an index with massive duplicates or fails to create an index
> when appropriate, it has created a major bottleneck. Interbase
> always creates an index for foreign keys and often suffers for
> it.

I completely agree here and would love to see a version of FB/IB with an
option for this.

> The second issue is that the nature of a professionally written
> application, particularly a professionally written web application
> that only presents users only valid choices, just doesn't lead to
> referential integrity problems.

In the context you put this here, it makes sense. You're absolutely right
that the app should only present valid choices, and that any cycles spent
validating what we already know are probably wasted.

Where RI is more useful to me is in either preventing deletions of records
referenced by other records or providing cascades to facilitate it. Yes,
one can implement these directly, but you need some kind of structure to
tell you where to look, and the FK definition is a reasonable structure for
that.

If you don't mind the digression, would you mind talking about alternate
ways of handling RI checks before deletes and/or cascades?

Thanks,

-Craig

--
Craig Stuntz Vertex Systems Corporation
Senior Developer http://www.vertexsoftware.com