「カスケードの削除」制約を追加するにはどうすればよいですか?


163

PostgreSQL 8ではON DELETE CASCADES、後者を削除せずに、次の表の両方の外部キーに追加できますか?

# \d scores
        Table "public.scores"
 Column  |         Type          | Modifiers
---------+-----------------------+-----------
 id      | character varying(32) |
 gid     | integer               |
 money   | integer               | not null
 quit    | boolean               |
 last_ip | inet                  |
Foreign-key constraints:
   "scores_gid_fkey" FOREIGN KEY (gid) REFERENCES games(gid)
   "scores_id_fkey" FOREIGN KEY (id) REFERENCES users(id)

参照されている両方のテーブルを以下に示します-ここに:

# \d games
                                     Table "public.games"
  Column  |            Type             |                        Modifiers
----------+-----------------------------+----------------------------------------------------------
 gid      | integer                     | not null default nextval('games_gid_seq'::regclass)
 rounds   | integer                     | not null
 finished | timestamp without time zone | default now()
Indexes:
    "games_pkey" PRIMARY KEY, btree (gid)
Referenced by:
    TABLE "scores" CONSTRAINT "scores_gid_fkey" FOREIGN KEY (gid) REFERENCES games(gid)

そしてここ:

# \d users
                Table "public.users"
   Column   |            Type             |   Modifiers
------------+-----------------------------+---------------
 id         | character varying(32)       | not null
 first_name | character varying(64)       |
 last_name  | character varying(64)       |
 female     | boolean                     |
 avatar     | character varying(128)      |
 city       | character varying(64)       |
 login      | timestamp without time zone | default now()
 last_ip    | inet                        |
 logout     | timestamp without time zone |
 vip        | timestamp without time zone |
 mail       | character varying(254)      |
Indexes:
    "users_pkey" PRIMARY KEY, btree (id)
Referenced by:
    TABLE "cards" CONSTRAINT "cards_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "catch" CONSTRAINT "catch_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "chat" CONSTRAINT "chat_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "game" CONSTRAINT "game_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "hand" CONSTRAINT "hand_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "luck" CONSTRAINT "luck_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "match" CONSTRAINT "match_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "misere" CONSTRAINT "misere_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "money" CONSTRAINT "money_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "pass" CONSTRAINT "pass_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "payment" CONSTRAINT "payment_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "rep" CONSTRAINT "rep_author_fkey" FOREIGN KEY (author) REFERENCES users(id)
    TABLE "rep" CONSTRAINT "rep_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "scores" CONSTRAINT "scores_id_fkey" FOREIGN KEY (id) REFERENCES users(id)
    TABLE "status" CONSTRAINT "status_id_fkey" FOREIGN KEY (id) REFERENCES users(id)

また、前のテーブルに2つのインデックスを追加するのは理にかなっているのでしょうか。

更新:ありがとうございました。また、メーリングリストで、1つのステートメントで管理できるため、明示的にトランザクションを開始しなくてもよいというアドバイスを受けました。

ALTER TABLE public.scores
DROP CONSTRAINT scores_gid_fkey,
ADD CONSTRAINT scores_gid_fkey
   FOREIGN KEY (gid)
   REFERENCES games(gid)
   ON DELETE CASCADE;

1
少しOTですが、参照している列にインデックスを作成していません(たとえば、pref_scores.gid)。参照されたテーブルで削除を行うと、それらのテーブルに多数の行が含まれる場合、削除を行わないと時間がかかります。一部のデータベースは、参照する列にインデックスを自動的に作成します。PostgreSQLは、それが価値のない場合があるので、あなたに任せます。
kgrittn 2012

1
ありがとうございました!削除には時間がかかることに実際に気づきましたが、その理由がわかりませんでした
Alexander Farber 2012

1
外部キーのインデックスに価値がない場合、どのケースでしょうか?
アレクサンダーファーバー2012

2
私はあなたの発見を私の答えに組み込んだ。(その単一のステートメントも単一のトランザクションです。)
Mike Sherrill 'Cat Recall'

2
@AlexanderFarber:FKの参照列のインデックスをいつ省略したいですか?十分に機能する完全一致ではない別のインデックスがある場合(たとえば、FK削除でも問題のない、頻繁な類似性検索用のトライグラムインデックスがある場合があります)。削除の頻度が低く、営業時間外にスケジュールできる場合。テーブルが参照値を頻繁に更新する場合。参照テーブルが非常に小さいが頻繁に更新される場合。例外は頻繁に発生するため、PostgreSQLコミュニティは自動化するよりも制御することを好みます。
kgrittn 2012

回答:


218

on delete cascade既存の外部キー制約に単純に追加することはできないと確信しています。最初に制約を削除してから、正しいバージョンを追加する必要があります。標準SQLでは、これを行う最も簡単な方法は

  • トランザクションを開始し、
  • 外部キーをドロップし、
  • で外部キーを追加しon delete cascade、最後に
  • トランザクションをコミットする

変更する外部キーごとに繰り返します。

ただし、PostgreSQLには非標準の拡張機能があり、1つのSQLステートメントで複数の制約句を使用できます。例えば

alter table public.scores
drop constraint scores_gid_fkey,
add constraint scores_gid_fkey
   foreign key (gid)
   references games(gid)
   on delete cascade;

削除する外部キー制約の名前がわからない場合は、pgAdminIIIで検索できます(テーブル名をクリックしてDDLを表示するか、「制約」が表示されるまで階層を展開します)。または、情報スキーマ照会できます

select *
from information_schema.key_column_usage
where position_in_unique_constraint is not null

ありがとう、それも私が考えたことですが、FOREIGN KEYをどうするか?それらは、(NOT NULLに似た)制約であり、簡単に削除および再読み込みできますか?
Alexander Farber

2
@AlexanderFarber:はい、それらはあなたが簡単にドロップしたり追加したりできる名前付きの制約です。しかし、おそらくトランザクション内でそれを行いたいでしょう。回答を詳細に更新しました。
Mike Sherrill「Cat Recall」、

pgAdminIIIでotを検索するための+1。DROP CONSTRAINTコマンドとADD CONSTRAINTコマンドも用意されているので、クエリウィンドウにコピーアンドペーストして、コマンドを必要に応じて編集できます。
Dave Pile

クエリを作成した後、Postgres GUI(Navicat)がGUI内からこの変更を簡単に実行できることに気付きました。dl.dropboxusercontent.com
quq37nq1583x0lf

大きなテーブルの場合、これNOT VALIDは別のトランザクションで可能であり、検証することはできますか?私が持っている未回答の質問これについては。
TheCloudlessSky 2017年

11

@Mike Sherrill Cat Recallの答えに基づいて、これは私にとってうまくいきました:

ALTER TABLE "Children"
DROP CONSTRAINT "Children_parentId_fkey",
ADD CONSTRAINT "Children_parentId_fkey"
  FOREIGN KEY ("parentId")
  REFERENCES "Parent"(id)
  ON DELETE CASCADE;

5

使用法:

select replace_foreign_key('user_rates_posts', 'post_id', 'ON DELETE CASCADE');

関数:

CREATE OR REPLACE FUNCTION 
    replace_foreign_key(f_table VARCHAR, f_column VARCHAR, new_options VARCHAR) 
RETURNS VARCHAR
AS $$
DECLARE constraint_name varchar;
DECLARE reftable varchar;
DECLARE refcolumn varchar;
BEGIN

SELECT tc.constraint_name, ccu.table_name AS foreign_table_name, ccu.column_name AS foreign_column_name 
FROM 
    information_schema.table_constraints AS tc 
    JOIN information_schema.key_column_usage AS kcu
      ON tc.constraint_name = kcu.constraint_name
    JOIN information_schema.constraint_column_usage AS ccu
      ON ccu.constraint_name = tc.constraint_name
WHERE constraint_type = 'FOREIGN KEY' 
   AND tc.table_name= f_table AND kcu.column_name= f_column
INTO constraint_name, reftable, refcolumn;

EXECUTE 'alter table ' || f_table || ' drop constraint ' || constraint_name || 
', ADD CONSTRAINT ' || constraint_name || ' FOREIGN KEY (' || f_column || ') ' ||
' REFERENCES ' || reftable || '(' || refcolumn || ') ' || new_options || ';';

RETURN 'Constraint replaced: ' || constraint_name || ' (' || f_table || '.' || f_column ||
 ' -> ' || reftable || '.' || refcolumn || '); New options: ' || new_options;

END;
$$ LANGUAGE plpgsql;

注意:この関数初期外部キーの属性をコピーしません。外部テーブル名/列名のみを受け取り、現在のキーを削除して新しいキーに置き換えます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.