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;
ありがとうございました!削除には時間がかかることに実際に気づきましたが、その理由がわかりませんでした
—
Alexander Farber 2012
外部キーのインデックスに価値がない場合、どのケースでしょうか?
—
アレクサンダーファーバー2012
私はあなたの発見を私の答えに組み込んだ。(その単一のステートメントも単一のトランザクションです。)
—
Mike Sherrill 'Cat Recall'
@AlexanderFarber:FKの参照列のインデックスをいつ省略したいですか?十分に機能する完全一致ではない別のインデックスがある場合(たとえば、FK削除でも問題のない、頻繁な類似性検索用のトライグラムインデックスがある場合があります)。削除の頻度が低く、営業時間外にスケジュールできる場合。テーブルが参照値を頻繁に更新する場合。参照テーブルが非常に小さいが頻繁に更新される場合。例外は頻繁に発生するため、PostgreSQLコミュニティは自動化するよりも制御することを好みます。
—
kgrittn 2012
pref_scores.gid
)。参照されたテーブルで削除を行うと、それらのテーブルに多数の行が含まれる場合、削除を行わないと時間がかかります。一部のデータベースは、参照する列にインデックスを自動的に作成します。PostgreSQLは、それが価値のない場合があるので、あなたに任せます。