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