SQL Trigger: при обновлении первичного ключа, как определить, какая «удаленная» запись соответствует какой «вставленной» записи? - PullRequest
6 голосов
/ 08 июля 2011

Предположим, что я знаю, что обновление первичного ключа неверно.

Есть и другие вопросы, которые подразумевают, что записи в таблицах inserted и updated совпадают по позиции (первая из одной соответствует первой издругой.) Это факт или совпадение?

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

Ответы [ 3 ]

8 голосов
/ 08 июля 2011

нет совпадения вставленных + удаленных позиций строк виртуальной таблицы.

И нет, вы не можете сопоставлять строки

Некоторые опции:

  • есть еще один уникальный неизменяемый (для этого обновления) ключ для связывания строк
  • ограничение на действия в одной строке.
  • использовать хранимую процедуру с предложением OUTPUT для захвата до и после ключей
  • Триггер INSTEAD OF с предложением OUTPUT (TBH не уверен, что вы можете это сделать)
  • запретить обновления первичного ключа (добавлено после комментария)
2 голосов
/ 13 октября 2016

Каждая таблица может иметь один столбец идентификаторов. Столбцы идентичности не могут быть обновлены; им присваивается значение при вставке записей (или при добавлении столбца), и они никогда не могут изменяться. Если первичный ключ является обновляемым, он не должен быть столбцом идентификаторов. Итак, либо у таблицы есть другой столбец, который является столбцом идентификаторов, либо вы можете добавить к нему один. Нет правила, согласно которому столбец идентификаторов должен быть первичным ключом. Затем в триггере строки в вставленные и обновленные , имеющие одинаковое значение идентификатора, являются одной и той же строкой, и вы можете поддерживать обновление первичного ключа для нескольких строк одновременно.

1 голос
/ 09 июля 2011

Да - создайте поле "old_primary_key" в таблице, которую вы обновляете, и заполните его первым.

Ничего нельзя сделать, чтобы сопоставить вставленные и удаленные ключи записи таблицы psuedo - дажеесли вы храните их данные в журнальной таблице где-то.

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

Но это говорит о том, что прежде чем что-то делать, пожалуйста, найдите доску для мела и напишите 100 раз:

Я знаю, что обновление первичного ключаплохо.Я знаю, что обновление первичного ключа плохо.Я знаю, что обновление первичного ключа плохо.Я знаю, что обновление первичного ключа плохо.Я знаю, что обновление первичного ключа плохо....

:-) (шучу)

...