Как добавить ограничения на удаление каскада?

Question

Как добавить ограничения на удаление каскада?

106

В PostgreSQL 8 можно добавить "на удаление каскадов" к обоим внешним ключам в следующей таблице, не отбрасывая последнюю?

# \d pref_scores
        Table "public.pref_scores"
 Column  |         Type          | Modifiers
---------+-----------------------+-----------
 id      | character varying(32) |
 gid     | integer               |
 money   | integer               | not null
 quit    | boolean               |
 last_ip | inet                  |
Foreign-key constraints:
   "pref_scores_gid_fkey" FOREIGN KEY (gid) REFERENCES pref_games(gid)
   "pref_scores_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)

Обе приведенные таблицы ниже - здесь:

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

И здесь:

# \d pref_users
                Table "public.pref_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:
    "pref_users_pkey" PRIMARY KEY, btree (id)
Referenced by:
    TABLE "pref_cards" CONSTRAINT "pref_cards_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_catch" CONSTRAINT "pref_catch_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_chat" CONSTRAINT "pref_chat_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_game" CONSTRAINT "pref_game_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_hand" CONSTRAINT "pref_hand_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_luck" CONSTRAINT "pref_luck_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_match" CONSTRAINT "pref_match_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_misere" CONSTRAINT "pref_misere_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_money" CONSTRAINT "pref_money_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_pass" CONSTRAINT "pref_pass_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_payment" CONSTRAINT "pref_payment_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_rep" CONSTRAINT "pref_rep_author_fkey" FOREIGN KEY (author) REFERENCES pref_users(id)
    TABLE "pref_rep" CONSTRAINT "pref_rep_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_scores" CONSTRAINT "pref_scores_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)
    TABLE "pref_status" CONSTRAINT "pref_status_id_fkey" FOREIGN KEY (id) REFERENCES pref_users(id)

И также интересно, имеет ли смысл добавить 2 индекса в прежнюю таблицу?

ОБНОВЛЕНИЕ: Спасибо, а также я получил совет в списке рассылки, чтобы я мог управлять им в 1-м заявлении и, следовательно, не нужно транзакции:

ALTER TABLE public.pref_scores
DROP CONSTRAINT pref_scores_gid_fkey,
ADD CONSTRAINT pref_scores_gid_fkey
   FOREIGN KEY (gid)
   REFERENCES pref_games(gid)
   ON DELETE CASCADE;

Alexander Farber 27 апр. 2012, в 19:58

Источник

1

Немного ОТ, но я замечаю, что вы не создали индексы для ссылок на столбцы (например, pref_scores.gid ). Удаление из таблицы, на которую ссылаются, без них займет много времени, если в этих таблицах будет много строк. Некоторые базы данных автоматически создают индекс для ссылочных столбцов; PostgreSQL оставляет это на ваше усмотрение, поскольку в некоторых случаях это не стоит.
kgrittn 28 апр. 2012, в 01:16
1

Спасибо! Я действительно заметил, что удаление занимает много времени, но не знал, что причина
Alexander Farber 28 апр. 2012, в 08:57
1

В каких случаях, когда индексы на внешних ключах не стоят?
Alexander Farber 28 апр. 2012, в 09:00
0

@AlexanderFarber: хорошее напоминание о том, что PostgreSQL позволяет использовать несколько предложений ограничений в одном выражении. Поскольку мне приходится поддерживать несколько платформ, я склонен полагаться на стандартный SQL. Я часто забываю об этих полезных расширениях.
Mike Sherrill 'Cat Recall' 28 апр. 2012, в 10:25
2

Я включил ваш вывод в мой ответ. (Это единственное утверждение также является одной транзакцией.)
Mike Sherrill 'Cat Recall' 28 апр. 2012, в 10:32
2

@AlexanderFarber: Когда вы могли бы опустить индекс в ссылочных столбцах FK? Когда есть другой индекс, который не является точным соответствием, который будет работать достаточно хорошо (например, у вас может быть индекс триграммы для частых поисков сходства, что также будет хорошо для удаления FK). Когда удаление происходит нечасто и может быть запланировано в нерабочее время. Когда таблица имеет частые обновления значения ссылки. Когда таблица ссылок очень мала, но часто обновляется. Исключения случаются достаточно часто, и сообщество PostgreSQL предпочитает контролировать его, а не делать его автоматическим.
kgrittn 28 апр. 2012, в 18:44

Показать ещё 4 комментария

Теги:

postgresql

constraints

cascade

postgresql-8.4

cascading-deletes

2 ответа

3

Использование:

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;

Знайте: эта функция не скопирует атрибуты исходного внешнего ключа. Он принимает только имя имени/столбца внешней таблицы, отбрасывает текущий ключ и заменяет новым.

Dan Key 03 окт. 2015, в 09:42

Ещё вопросы

Немного ОТ, но я замечаю, что вы не создали индексы для ссылок на столбцы (например, pref_scores.gid ). Удаление из таблицы, на которую ссылаются, без них займет много времени, если в этих таблицах будет много строк. Некоторые базы данных автоматически создают индекс для ссылочных столбцов; PostgreSQL оставляет это на ваше усмотрение, поскольку в некоторых случаях это не стоит.
Спасибо! Я действительно заметил, что удаление занимает много времени, но не знал, что причина
В каких случаях, когда индексы на внешних ключах не стоят?
@AlexanderFarber: хорошее напоминание о том, что PostgreSQL позволяет использовать несколько предложений ограничений в одном выражении. Поскольку мне приходится поддерживать несколько платформ, я склонен полагаться на стандартный SQL. Я часто забываю об этих полезных расширениях.
Я включил ваш вывод в мой ответ. (Это единственное утверждение также является одной транзакцией.)
@AlexanderFarber: Когда вы могли бы опустить индекс в ссылочных столбцах FK? Когда есть другой индекс, который не является точным соответствием, который будет работать достаточно хорошо (например, у вас может быть индекс триграммы для частых поисков сходства, что также будет хорошо для удаления FK). Когда удаление происходит нечасто и может быть запланировано в нерабочее время. Когда таблица имеет частые обновления значения ссылки. Когда таблица ссылок очень мала, но часто обновляется. Исключения случаются достаточно часто, и сообщество PostgreSQL предпочитает контролировать его, а не делать его автоматическим.

Mike Sherrill 'Cat Recall' · Accepted Answer · 2012-04-27T20-49-00.000Z

Я уверен, вы не можете просто добавить on delete cascade к существующему ограничению внешнего ключа. Сначала нужно отбросить ограничение, а затем добавить правильную версию. В стандартном SQL я считаю, что самый простой способ сделать это -

начать транзакцию,
удалить внешний ключ,
добавьте внешний ключ с on delete cascade и, наконец,
совершить транзакцию

Повторите для каждого внешнего ключа, который вы хотите изменить.

Но PostgreSQL имеет нестандартное расширение, которое позволяет использовать несколько предложений ограничений в одном выражении SQL. Например

alter table public.pref_scores
drop constraint pref_scores_gid_fkey,
add constraint pref_scores_gid_fkey
   foreign key (gid)
   references pref_games(gid)
   on delete cascade;

Если вы не знаете имя ограничения внешнего ключа, которое хотите отбросить, вы можете просмотреть его в pgAdminIII (просто щелкните имя таблицы и посмотрите на DDL или разверните иерархию, пока не увидите "Ограничения" ), или вы можете запросить информационную схему.

select *
from information_schema.key_column_usage
where position_in_unique_constraint is not null

Спасибо, я тоже так думал, но что делать с КНОПКАМИ ИНОСТРАННЫХ? Являются ли они просто ограничениями (похожими на NOT NULL), которые можно легко удалить и прочитать?
@AlexanderFarber: Да, они названы ограничениями, которые вы можете легко удалить и добавить. Но вы, вероятно, хотите сделать это в рамках транзакции. Обновил мой ответ более подробно.
+1 за поиск в pgAdminIII. Он даже дает вам команды DROP CONSTRAINT и ADD CONSTRAINT, так что вы можете просто скопировать и вставить в окно запроса и отредактировать команду так, как вам нужно.
После написания запроса я заметил, что мой Postgres GUI (Navicat) позволяет мне тривиально сделать это изменение из GUI: dl.dropboxusercontent.com/spa/quq37nq1583x0lf/wwqne-lw.png
Для больших таблиц это возможно с NOT VALID и проверкой в отдельной транзакции? У меня есть вопрос без ответа по этому поводу.
@TheCloudlessSky: PostgreSQL поддерживает объявление ограничений внешнего ключа как not valid в одной транзакции и проверку их с помощью alter table table_name validate constraint constraint_name; в другой транзакции. Вы можете проверить это на небольших столах.