SQL Trigger для ведения истории изменений

Question

У меня есть три таблицы:

Table1: Customers (CustomerId, Name, CustomerAddress)
Table2: AccountManagers(ManagerId, Name)
Table3: CustomerAccountManagers (CustomerId, ManagerId, Remarks)
Table4: CustomerHistory(CustomerAddress, ManagerId, Date)

Таблица CustomerHistory используется для хранения любых изменений, внесенных в «CustomerAddress» ИЛИ «ManagerId», например, CustomerAddress обновляется с «Address1» до «Address2» ИЛИCustomerAccountManager изменяется с «Manager1» на «Manager2».

Мне нужно сохранить изменения в таблице CustomerHistory с помощью SQL Trigger.Вопрос в том, на каком столе должен быть мой триггер?Обратите внимание, что изменения вносятся одновременно в обе таблицы: «Клиенты» и «CustomerAccountManagers».

Спасибо

Answer 1

Прежде всего, таблица CustomerHistory, вероятно, должна также содержать CustomerId, чтобы запись истории можно было отследить до нужного клиента.

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

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

Answer 2

Вам нужно добавить свой триггер в таблицу, где изменения данных «вызовут» необходимость что-то сделать.

Таким образом, триггер в таблице Customers для отслеживания изменений CustomerAddress и триггер в CustomerAccountManagers при изменении ManagerId.

Answer 3

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

Наконец, если вам нужно, вы можете создать представление CustomerHistory, объединяющее различные исторические таблицы.