これらの機能が何をするのか、そしていつそれらを使用するのが適切であるのかについて、誰かが明確な説明/例を提供できますか?
4 に答える
マニュアルからそのまま...
外部キーにより、どの製品にも関係のない注文の作成が許可されないことがわかっています。しかし、製品を参照する注文が作成された後に製品が削除された場合はどうなるでしょうか? SQL を使用すると、それを処理することもできます。直感的に、いくつかのオプションがあります。
参照製品の削除を許可しない
注文も削除
他の何か?
CREATE TABLE order_items (
product_no integer REFERENCES products ON DELETE RESTRICT,
order_id integer REFERENCES orders ON DELETE CASCADE,
quantity integer,
PRIMARY KEY (product_no, order_id)
);
削除の制限とカスケードは、最も一般的な 2 つのオプションです。RESTRICT は、参照された行の削除を防ぎます。NO ACTION は、制約のチェック時に参照行がまだ存在する場合、エラーが発生することを意味します。これは、何も指定しない場合のデフォルトの動作です。(これら 2 つの選択肢の本質的な違いは、NO ACTION ではトランザクションの後半までチェックを延期できるのに対し、RESTRICT ではそれができないことです。) CASCADE は、参照された行が削除されたときに、それを参照している行を自動的に削除する必要があることを指定します。同じように。他に、SET NULL と SET DEFAULT の 2 つのオプションがあります。これらにより、参照される行が削除されると、参照する列がそれぞれ NULL またはデフォルト値に設定されます。これらは、制約を遵守することを免除するものではないことに注意してください。例えば、
ON DELETE と同様に、参照列が変更 (更新) されたときに呼び出される ON UPDATE もあります。可能なアクションは同じです。
編集:この関連する質問をご覧になることをお勧めします: SQL Server でカスケードを使用する場合と理由は? . 質問/回答の背後にある概念は同じです。
カスケード削除またはカスケード更新のすべての作業を実行するメソッドを作成する代わりに、代わりに警告メッセージを作成することができます。車輪の再発明よりもはるかに簡単で、クライアント(およびコードを取得する新しい開発者)に明確になります
ダオクの言うことは本当です...それはかなり便利です。一方で、データベース内で自動的に処理を行うことは、特にデータの消去に関しては、実際の問題になる可能性があります。将来、FK は通常、子がいる場合に親の削除を防止するという事実を当てにして、On Delete Cascade を使用しても削除が防止されないだけでなく、大量のデータが大量に作成されることに気付かない可能性があります。カスケード削除のウォーターフォールのおかげで、他のテーブルはなくなります。
@アーサーのコメント。
データベースで「隠れた」ことが頻繁に発生するほど、何が起こっているのかを適切に把握できる可能性が低くなります。トリガー (およびこれは本質的にトリガーです) は、行を削除するという単純なアクションを引き起こし、データベース全体に幅広い結果をもたらす可能性があります。Delete ステートメントを発行すると、17 個のテーブルがトリガーと制約のカスケードの影響を受けますが、コマンドの発行者にはすぐにはわかりません。OTOH、親とそのすべての子の削除をプロシージャに配置すると、コマンドを発行したときに何が起こるかを誰にとっても非常に簡単かつ明確にわかります。
データベースをどれだけうまく設計できるかは、まったく関係ありません。トリガーによって導入された運用上の問題と関係があります。
PostGreSQL データベースがあり、データベースから削除するユーザーがいて、その情報を他のテーブルから削除する必要がある場合は、On Delete を使用します。この方法では、削除を 1 回だけ行う必要があり、削除が ON の FK は他のテーブルから情報を削除します。
ON Update でも同じことができます。テーブルを更新し、フィールドに [更新時] の FK がある場合、FK に変更が加えられると、FK テーブルで通知されます。