|Subject||Re: [IB-Architect] Circular Foreign Key Dependencies|
> Circular foreign key dependencies are natural andAgreed.
> useful (contentious statement #1),
> but a near disaster from a DDL perspective (contentiousAnd they can make data transfers quite complicated, since the order in
> statement #2) since a table can't be dropped with another
> table referencing it,
which data must be extracted or imported can become convoluted.
> and there is no easy to delete an unnamed foreignWhy unnamed? Can you explain a bit more about what you mean here and
> key constraint.
why it is a problem or solution to this situation.
> Anybody have any rare and keen insight intoI doubt if its rare or all that keen, but IMO we still need the
> the problem?
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.