Как обновить первичный ключ таблицы, который упоминается как внешний ключ в другой таблице?

Question

Допустим,

Table "Person" having 
    "SSN",
    "Name",
    "Address"

и еще

Table "Contacts" having
    "Contact_ID",
    "Contact_Type",
    "SSN" (primary key of Person)

аналогично

Table "Records" having
    "Record_ID",
    "Record_Type",
    "SSN" (primary key of Person)

Теперь я хочу, чтобы при изменении или обновлении SSN в персональной таблице это изменилось в других 2 таблицах.

1. Если кто-нибудь может помочь мне с триггером для этого
2. Или как передать ограничения внешнего ключа для таблиц

Answer 1

Просто добавьте ON UPDATE CASCADE в ограничение внешнего ключа.

Answer 2

Желательно, чтобы первичный ключ таблицы никогда не менялся. Если вы ожидаете, что SSN изменится, вы должны использовать другой первичный ключ и иметь SSN в качестве обычного столбца данных в таблице персонала. Если уже слишком поздно вносить это изменение, вы можете добавить ON UPDATE CASCADE в ограничение внешнего ключа.

Answer 3

Если у вас есть PK, которые меняются, вам нужно взглянуть на дизайн таблицы, использовать суррогатный PK, как личность.

В вашем вопросе у вас есть таблица Person, которая может быть FK для многих таблиц. В этом случае у ON UPDATE CASCADE могут возникнуть серьезные проблемы. База данных, над которой я работаю, насчитывает более 300 ссылок (FK) на нашу эквивалентную таблицу, мы отслеживаем всю различную работу, которую человек выполняет в каждой отдельной таблице. Если я вставлю строку в нашу таблицу Person, а затем попытаюсь снова удалить ее (она не будет использоваться в других таблицах, она новая), то при удалении произойдет ошибка Msg 8621, Level 17, State 2, Line 1 The query processor ran out of stack space during query optimization. Please simplify the query.. ON UPDATE CASCADE будет работать, когда вы получите много ПК на вашем ПК.

Я бы никогда не сделал конфиденциальные данные, такие как SSN, PK. Медицинские компании раньше делали это и имели болезненный переход из-за конфиденциальности. Я надеюсь, что у вас нет веб-приложения и есть переменная GET или POST с именем SSN с фактическим значением в нем !! Или отображать SSN в каждом отчете, или вы уничтожите все старые печатные отчеты и ограничите доступ к просмотру каждого отчета и т. Д.

Answer 4

Каскадное обновление и удаление очень опасны для использования. Если у вас есть миллион дочерних записей, вы можете столкнуться с серьезной проблемой блокировки. Вместо этого вы должны закодировать обновления и удалить.

Вы никогда не должны использовать PK с возможностью изменения, если этого можно избежать. Также вы никогда не должны использовать SSN в качестве PK, потому что он никогда не должен храниться в незашифрованном виде в вашей базе данных. Никогда, кроме случаев, когда вашей компании нравится предъявлять иск, когда они являются причиной инцидента с кражей личных данных. Это не недостаток дизайна, который нужно игнорировать, так как это наследие, у нас нет времени на исправление. Это конструктивный недостаток, который может обанкротить вашу компанию, если кто-то украдет ваши резервные ленты или по-другому получит ssns из системы (большинство этих типов краж - внутренние BTW). Это срочно - нужно исправить сейчас недостаток дизайна.

SSN также является плохим кандидатом, потому что он меняется (люди меняют их, например, когда они становятся жертвами кражи личных данных). Плюс целое число PK будет иметь более высокую производительность, чем число из девяти цифр.

Answer 5

Ну, предполагая, что SSN является первичным ключом таблицы Person, я бы просто (в транзакции, конечно):

• создать новую строку с новым SSN, скопировав все остальные детали из старой строки.
• обновить столбцы в других таблицах, чтобы они указывали на новую строку.
• удалить старую строку.

Теперь это действительно хороший пример того, почему вы не должны использовать реальные данные в качестве перекрестных ссылок на таблицы, если эти данные могут измениться. Если бы вы использовали искусственный столбец, чтобы связать их вместе (и хранили SSN только в одном месте), у вас не возникло бы проблемы.