> Circular foreign key dependencies are natural and
> useful (contentious statement #1),

Agreed.

> but a near disaster from a DDL perspective (contentious
> statement #2) since a table can't be dropped with another
> table referencing it,

And they can make data transfers quite complicated, since the order in
which data must be extracted or imported can become convoluted.

> and there is no easy to delete an unnamed foreign
> key constraint.

Why unnamed? Can you explain a bit more about what you mean here and
why it is a problem or solution to this situation.

> Anybody have any rare and keen insight into
> the problem?

I doubt if its rare or all that keen, but IMO we still need the
ability to define circular dependancies.

I got the impression that some of the reserved metadata items in
Interbase may be referring to ways around this problem - the deferred
and initially_deferrable stuff.

I thought that it may be intended to allow certain actions to be
deferred before data integrity constraints are applied.

Allowing, for example, a table to be deleted and then the various
constraints changed/removed before attempting to validate the changes.
Similarly for the actual DML operations, let a record be
inserted/removed/updated without validation, so that additional
operations can take place which will permit the validation processes
(that have been deferred) to succeed.

I am not trying to pretend that this would be easy but it does seem
like it may be a way around the problem. I am not certain how long
the validation deferral should last. Whether it would be under
application control or whether it may simply be deferred until commit.


Geoff Worboys
Telesis Computing