Триггеры для совместимости схемы

Question

Вот хороший, я думаю. Начнем с того, что я на самом деле не знаю, что такое триггер, который сейчас может стать очевидным.

Хороши ли триггеры для обеспечения обратной совместимости между схемами базы данных?

Скажем, у меня есть отношение 1-ко-многим в версии 1. В версии 2 оно было изменено на "многие-ко-многим". Может ли правильно реализованный триггер справиться с этим, чтобы обе версии могли работать в одной базе данных? Это хорошая идея?

Answer 1

Реализация обратной совместимости никогда не бывает простой.Представьте, что у вас есть (версия 1):

CREATE TABLE T1 (
    ID int not null primary key,
    ColA varchar(10) not null
)
CREATE TABLE T2 (
    ID int not null primary key,
    T1ID int not null,
    ColB varchar(10) not null,
    constraint FK_T2_T1 FOREIGN KEY (T1ID) references T1
)

, а теперь, для версии 2, вы хотите ввести:

CREATE TABLE T1_T2 (
    T1ID int not null,
    T2ID int not null,
    constraint PK_T1_T2 PRIMARY KEY (T1,T2),
    constraint FK_T1_T2_T1 FOREIGN KEY (T1ID) references T1,
    constraint FK_T1_T2_T2 FOREIGN KEY (T2ID) references T2
)

И, как я понимаю из вашего вопроса, вымыслительная активность на T1_T2 может поддерживать существующий столбец T1ID в T2 для обратной совместимости.

Конечно, возможно , чтобы это произошло, но у вас есть целая нагрузкапроблемы для решения:

• Какое значение T1ID вы записываете в T2, если в T1_T2?
• есть несколько строк, что должно произойти, что должно произойтив T1ID in T2 - установить NULL, выбрать другое значение?
• Что если все строки, соответствующие T2ID, будут удалены из T1_T2.Строка из T2 должна быть удалена?T1ID установить NULL?
• Если приложение версии 1 обновляет T1ID в T2, а в T1_T2 нет строк, это ошибка или должна быть вставлена ​​новая строка?
• Может ли приложение версии 1 предположить, что оно может удалить строку из T1, если ни одна строка в T2 не имеет этого конкретного T1ID

Я уверен, что есть еще многоЧто ж.Вы можете решить все эти проблемы, но вам никогда не удастся идеально смоделировать старое поведение для 100% использования схемы Версии 1.

---

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

Answer 2

Да, вы могли бы сделать это, используя триггер INSTEAD OF для вставок, обновлений и удалений в представлении для старой версии.Чтобы сделать это более понятным, давайте рассмотрим следующий пример:

v1:
    A(id int, data varchar(30))
    B(id int, a_id int, data varchar(30))

v2:
    A(id int, data varchar(30))
    B(id int, data varchar(30), data2 varchar(20))
    AB(a_id int, b_id int)

Сначала вы должны создать представление, имитирующее старую версию таблицы B.Сложно было бы решить, какие из отношений AB показывать старому приложению.Один из вариантов - добавить столбец primary_b типа bit в таблицу AB.Представление ниже использует эту опцию

CREATE VIEW OldB AS 
    SELECT B.id AS id, AB.a_id AS a_id, B.data AS data,  
    FROM B INNER JOIN AB ON B.id = AB.b_id
    WHERE AB.primary_b = 1

Далее вы должны создать триггеры в представлении для обработки вставок и обновлений.

CREATE TRIGGER InsertTrigger on OldB INSTEAD OF INSERT
AS
BEGIN

INSERT INTO B (id, data) SELECT id, data FROM inserted;
UPDATE AB SET primary_b = 0 WHERE b_id IN (SELECT id FROM inserted);
INSERT INTO AB (a_id, b_id, primary_b) SELECT a_id, id, 1 FROM inserted;

END 
GO

Вместо обновления вы бы сделали нечто подобное, за исключением того, что вам пришлось бы управлять изменением ссылок A на B, удаляя и добавляя строки в AB.Я еще не проверил этот код на наличие ошибок, но через час или около того я опубликую обновление, если это необходимо.

Answer 3

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