Peter Geoghegan wrote:
> If we followed this behaviour, we wouldn't "let people just
> arbitrarily claim" that a referential condition exists - rather,
> we'd let them assert that it /ought/ to exist, and that it will be
> maintained going forward, and give them the option of verifying
> that assertion at a later time, after which it actually exists.
What you outline would be quite valuable to our shop. Under the
law, the "custodians of the data" are the elected clerks of circuit
court, and under state law and rules of the state supreme court we
can't "clean up" even the most glaring apparent data problems
without the OK of the elected official or his or her designee. We
have a very complex schema (although no more complex than necessary
to model the reality of the data) with hundreds of foreign key
relationships.
For various reasons (conversions from old systems, etc.), these
relationships don't hold on all tables in all county databases. It
would be desirable to have foreign key definitions define the
intended relationships anyway, and very useful for them to prevent
further data degradation. For those situations where we get a
business analyst to work with clerk of court staff to clean up
orphaned rows, it would be very slick to be able to run some
statement (like CHECK DATA) to see if the cleanup is complete and
successful and to flag that the constraint is now enforced.
So +1 on what Peter outlined as current DB2 features in this regard.
-Kevin