Postgres外部キーの「更新時」および「削除時」オプションはどのように機能しますか？

Question

これらの関数が何をするのか、いつ使用するのが適切か、明確な説明/例を提供できますか？

Answer 1

マニュアルからのストレート...

  

外部キーは、製品に関係のない注文の作成を許可しないことを知っています。しかし、それを参照する注文が作成された後に製品が削除された場合はどうなりますか？ 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は、参照行が削除されると、それを参照する行を自動的に削除することを指定します同様に。他にも2つのオプションがあります。SETNULLとSET DEFAULTです。これらにより、参照された行が削除されると、参照する列がそれぞれヌルまたはデフォルト値に設定されます。これらは制約を遵守することを許さないことに注意してください。たとえば、アクションがSET DEFAULTを指定しているが、デフォルト値が外部キーを満たさない場合、操作は失敗します。

     

ON DELETEと同様に、参照列が変更（更新）されたときに呼び出されるON UPDATEもあります。可能なアクションは同じです。

編集：次の関連する質問をご覧ください： SQL Serverでカスケードを使用するタイミング/理由は何ですか。質問/回答の背後にある概念は同じです。

Answer 2

PostGreSQLデータベースがあり、データベースから削除するユーザーがいて、その情報を他のテーブルから削除する必要がある場合、削除時に使用します。この方法で1つの削除だけを行う必要があり、削除がONのFKは他のテーブルから情報を削除します。

ONアップデートでも同じことができます。テーブルを更新し、フィールドに更新時のFKがある場合、FKに変更が加えられると、FKテーブルに気づきます。

Answer 3

Daokの言うことは本当です...かなり便利です。一方、データベース内で自動的に処理を実行することは、特にデータを削除する場合に大きな問題になる可能性があります。将来、FKは通常、子供がいるときに親の削除を防止し、On Delete Cascadeの使用が削除を防止しないだけでなく、何十もの大量のデータを作成することに気付かないという事実を頼りにする可能性がありますカスケード削除の滝のおかげで、他のテーブルはなくなります。

@Arthurのコメント。

より頻繁に＆quot; hidden＆quot ;;データベースで何かが起こると、誰もが起こっていることをうまく処理できる可能性が低くなります。トリガー（これは本質的にトリガーです）を使用すると、行を削除するという単純なアクションが発生し、データベース全体にさまざまな結果をもたらす可能性があります。 Deleteステートメントを発行すると、17のテーブルがトリガーと制約のカスケードの影響を受け、コマンドの発行者にはこれがすぐにはわかりません。 OTOH、親とそのすべての子の削除をプロシージャに入れると、コマンドを発行したときに何が起こるかを誰でも正確に確認できます。

データベースの設計の仕方とはまったく関係ありません。トリガーによって導入された運用上の問題に関係しています。

Answer 4

カスケード削除またはカスケード更新のすべての作業を行うメソッドを作成する代わりに、代わりに単に警告メッセージを作成することができます。車輪を再発明するよりもはるかに簡単で、クライアント（および新しい開発者がコードを選択する）に明確になります