SQL Trigger: при обновлении первичного ключа Как определить, какая "удаленная" запись отвечает на какую "вставленную" запись?

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

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

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

6
sql sql-server-2005 triggers tsql

3 ответов

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

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

варианты:

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

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

2

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

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

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

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

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

:-) (шучу)

1