Я регулярно использую «ON DELETE CASCADE», но никогда не пользуюсь «ON UPDATE CASCADE», так как не уверен, в какой ситуации это будет полезно.
Ради обсуждения, давайте посмотрим код.
CREATE TABLE parent (
id INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY (id)
);
CREATE TABLE child (
id INT NOT NULL AUTO_INCREMENT, parent_id INT,
INDEX par_ind (parent_id),
FOREIGN KEY (parent_id)
REFERENCES parent(id)
ON DELETE CASCADE
);
Для "ON DELETE CASCADE", если родительский элемент с id
удален, запись в дочернем элементе с parent_id = parent.id
будет автоматически удалена. Это должно быть без проблем.
Это означает, что «ON UPDATE CASCADE» будет делать то же самое при
id
обновлении родительского элемента?Если (1) имеет значение true, это означает, что нет необходимости использовать «ON UPDATE CASCADE», если
parent.id
он не обновляется (или никогда не будет обновляться), например, когда он установленAUTO_INCREMENT
или всегда установленTIMESTAMP
. Это правильно?Если (2) неверно, в какой другой ситуации мы должны использовать «ОБНОВЛЕНИЕ КАСКАДА»?
Что если я (по какой-то причине) обновлю что-
child.parent_id
то, что не существует, будет ли оно автоматически удалено?
Ну, я знаю, некоторые из приведенных выше вопросов можно протестировать программно, чтобы понять, но я также хочу знать, зависит ли что-либо из этого от поставщика базы данных или нет.
Пожалуйста, пролите немного света.
Ответы:
Это правда, что если ваш первичный ключ представляет собой просто значение идентификатора, которое автоматически увеличивается, у вас не будет реального использования ON UPDATE CASCADE.
Однако предположим, что ваш первичный ключ - это 10-значный штрих-код UPC, и в связи с расширением его необходимо заменить на 13-значный штрих-код UPC. В этом случае ON UPDATE CASCADE позволит вам изменить значение первичного ключа, и любые таблицы, имеющие ссылки на внешний ключ, будут соответственно изменены.
В отношении # 4, если вы измените дочерний идентификатор на то, чего нет в родительской таблице (и у вас есть ссылочная целостность), вы должны получить ошибку внешнего ключа.
источник
ON UPDATE CASCADE
себя для обновления первичных ключей в старой таблице, которая не использует автоинкрементный ключДа, это означает, что, например, если вы
UPDATE parent SET id = 20 WHERE id = 10
все дети, parent_id из 10 также будет обновлен до 20Если вы не обновите поле, на которое ссылается внешний ключ, этот параметр не требуется
Не могу думать ни о каком другом использовании.
Вы не можете сделать это, так как ограничение внешнего ключа потерпит неудачу.
источник
Я думаю, что вы в значительной степени прибили очки!
Если вы следуете передовым методам проектирования баз данных и ваш первичный ключ никогда не обновляется (что, я думаю, всегда должно быть так), тогда вам никогда не понадобится это
ON UPDATE CASCADE
предложение.Зед отметил , что если вы используете естественный ключ (например, обычное поле из таблицы базы данных) в качестве первичного ключа, то могут возникнуть ситуации, когда вам необходимо обновить свои первичные ключи. Другим недавним примером может быть ISBN (международные стандартные номера книг), который не так давно изменился с 10 до 13 цифр + символов.
Это не тот случай, если вы решите использовать суррогатные (например, искусственно сгенерированные системой) ключи в качестве первичного ключа (что будет моим предпочтительным выбором во всех случаях, кроме самых редких случаев).
Итак, в конце концов: если ваш первичный ключ никогда не изменяется, тогда вам никогда не понадобится
ON UPDATE CASCADE
предложение.Марк
источник
colors
со строкамиblue
,purple
,yellow
, и столproducts
сproduct_color
колонки, будучи FK'ed кcolors
столу. Это ограничивает выбор, например, перечисление, но в отличие от целочисленного с автоматическим приращением, для получения имени цвета не требуется объединение. В таком случае,on update cascade
это хорошая идея, если вы решили, что вместо этогоpurple
следует вызватьviolet
.Несколько дней назад у меня была проблема с триггерами, и я понял, что это
ON UPDATE CASCADE
может быть полезно. Взгляните на этот пример (PostgreSQL):В моем выпуске я должен был определить некоторые дополнительные операции (триггер) для обновления таблицы концерта. Эти операции должны были изменить club_name и band_name. Я не смог этого сделать из-за ссылки. Я не мог изменить концерт и затем иметь дело со столами клуба и группы. Я также не мог сделать это по-другому.
ON UPDATE CASCADE
был ключом к решению проблемы.источник
SERIAL
колонки вclub
и вband
качестве первичных ключей , если вы ссылаетесьname
с вместо первичного ключа каждой таблицы?Мой комментарий в основном относится к пункту № 3: при каких обстоятельствах применяется ON UPDATE CASCADE, если мы предполагаем, что родительский ключ не подлежит обновлению? Вот один случай.
Я имею дело со сценарием репликации, в котором несколько спутниковых баз данных должны быть объединены с главной. Каждый спутник генерирует данные в одних и тех же таблицах, поэтому объединение таблиц с ведущим ведет к нарушению ограничения уникальности. Я пытаюсь использовать ON UPDATE CASCADE как часть решения, в котором я заново увеличиваю ключи при каждом слиянии. ОБНОВЛЕНИЕ CASCADE должно упростить этот процесс за счет автоматизации части процесса.
источник
Это отличный вопрос, у меня вчера был тот же вопрос. Я думал об этой проблеме, в частности, ПОИСК, если существовало что-то вроде «ОБНОВЛЕНИЕ КАСКАДА», и, к счастью, разработчики SQL тоже думали об этом. Я согласен с Ted.strauss, и я также прокомментировал дело Норана.
Когда я использовал это? Как указал Тед, когда вы обрабатываете несколько баз данных одновременно, и изменение в одной из них, в одной таблице, имеет какое-либо воспроизведение в том, что Тед называет «спутниковой базой данных», невозможно сохранить с самой оригинальной ID, и по любой причине вам нужно создать новый, в случае, если вы не можете обновить данные в старом (например, из-за разрешений, или если вы ищете скорость в случае, который настолько эфемерен, что не заслуживает абсолютного и полного уважения к общим правилам нормализации, просто потому что это будет очень недолгая утилита)
Итак, я согласен в двух моментах:
(А.) Да, во многих случаях лучший дизайн может избежать этого; НО
(B.) В случае миграции, репликации баз данных или решения чрезвычайных ситуаций, это КРАСИВЫЙ ИНСТРУМЕНТ, который, к счастью, был там, когда я отправился на поиск, если он существует.
источник