|
|
|
@ -1062,6 +1062,27 @@ CREATE TABLE order_items ( |
|
|
|
|
operation will fail. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
The appropriate choice of <literal>ON DELETE</literal> action depends on |
|
|
|
|
what kinds of objects the related tables represent. When the referencing |
|
|
|
|
table represents something that is a component of what is represented by |
|
|
|
|
the referenced table and cannot exist independently, then |
|
|
|
|
<literal>CASCADE</literal> could be appropriate. If the two tables |
|
|
|
|
represent independent objects, then <literal>RESTRICT</literal> or |
|
|
|
|
<literal>NO ACTION</literal> is more appropriate; an application that |
|
|
|
|
actually wants to delete both objects would then have to be explicit about |
|
|
|
|
this and run two delete options. In the above example, order items are |
|
|
|
|
part of an order, and it is convenient if they are deleted automatically |
|
|
|
|
if an order is deleted. But products and orders are different things, and |
|
|
|
|
so making a deletion of a product automatically cause the deletion of some |
|
|
|
|
order items could be considered problematic. The actions <literal>SET |
|
|
|
|
NULL</literal> or <literal>SET DEFAULT</literal> can be appropriate if a |
|
|
|
|
foreign-key relationship represents optional information. For example, if |
|
|
|
|
the products table contained a reference to a product manager, and the |
|
|
|
|
product manager entry gets deleted, then setting the product's product |
|
|
|
|
manager to null or a default might be useful. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
Analogous to <literal>ON DELETE</literal> there is also |
|
|
|
|
<literal>ON UPDATE</literal> which is invoked when a referenced |
|
|
|
|