 |
» |
|
|
|
If your databases contain tables that are interrelated
through rules and procedures or integrity constraints,
the job of maintaining them may be more difficult.
As you begin to restructure a database, be sure to study the
implications of loading and unloading, dropping and recreating
objects that have relationships to other objects. The following are
a few common situations that can lead to unexpected results:
Dropping a unique constraint also drops the B-tree index
that supports the constraint and deprives the optimizer
of one access path to the data in the table. Attempting to drop a table that is referenced by another table
results in an error. You must drop the constraint that
links the two tables, or else drop the referencing table first.
To drop the constraint, use the DROP CONSTRAINT clause
in the ALTER TABLE statement, specifying the referencing table. Dropping a table results in dropping of constraints
and rules built on it. If you are restructuring, and
you wish to drop and recreate the table, you must also recreate
the rules and constraints. Dropping a procedure does not drop rules that invoke the
procedure, but it does invalidate stored sections that depend
on invoking the procedure from a rule. The loss of the procedure
will be reported as an error when there is an attempt to revalidate
those sections. If you wish to drop rules associated with a
particular procedure, you should do so explicitly with DROP RULE
statements. A complex chaining set of rules and procedures will be
disrupted by the dropping of any rule or procedure in the chain.
If you are using rule chaining, it is your responsibility to
control the inventory of rules and procedures carefully.
|
