diff options
| -rw-r--r-- | doc/src/sgml/ddl.sgml | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 94f745aed03..642ea2a70d0 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -1063,6 +1063,27 @@ CREATE TABLE order_items ( </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 column is changed (updated). The possible actions are the same. |