Generic Insert Trigger

У меня следующий сценарий: две базы данных SQL Server 2008 (скажем, DB-A и DB-B). В обоих случаях у меня много таблиц. Для некоторых таблиц в DB-A мне нужно скопировать некоторые из вставленных записей (на основе условия) в ту же таблицу на DB-B. Конечно, обе таблицы должны иметь такую же структуру. Мой первоначальный подход заключается в создании триггеров для Insert в таблицах FROM DB-A, чтобы скопировать рекордеры в DB-B на основе условия. Теперь у меня есть две проблемы:Generic Insert Trigger

1) Есть ли способ записать эти триггеры на общий путь (без имен названий полей)?

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

2) Как я могу убедиться, что DB-B обновляется при редактировании записи из DB-A?

Записи из DB-A могут быть отредактированы после вставки, поэтому DB-B не будет знать об этом выпуске. Я мог бы создать триггер для обновления. Проблема заключается в первичных ключах, которые будут разными в обеих таблицах.

Любые идеи? благодаря!

источник

2014-12-19 ericpap

Это решаемая проблема. У многих умных людей уже есть инструменты для тиражирования, вы должны попробовать их, прежде чем запускать собственное решение. Для начала вам следует изучить инструменты, встроенные в Microsoft SQL Server. –

Вы говорите о транзакционной репликации? Проблема в том, что мне нужно только скопировать некоторые записи из таблицы DB-A в DB-B – ericpap

Этот сценарий не выглядит хорошим для триггеров. Если по какой-либо причине вставка в DB-B не удалась, INSERT в DB-A также будет откат. Вы не можете писать триггеры «общим» способом. Триггеры плохо влияют на производительность INSERT. Если по какой-то причине у вас нет спускового механизма на какое-то время, у вас нет гарантий, чем базы данных находятся в синхронизации.

Итак, если две базы данных должны синхронизироваться почти в режиме реального времени, я бы предложил транзакционную репликацию. Репликация вносит все изменения в опубликованные таблицы из одного БД в другой и синхронизирует данные. Таблицы исходных и целевых баз данных имеют одинаковые структуры. Поэтому, если таблицы в DB-B различны, это не сработает.

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

источник

2014-12-19 13:01:02 Alsin

Спасибо за ваше время и комментарий. Проблема с транзакционной репликацией заключается в том, что мне нужно только переместить НЕКОТОРЫЕ записи из таблицы DB-A в DB-B (на основе условия WHERE), а не всю таблицу. Подход SP мог бы работать, но каждый раз, когда он запускается, мне нужно проверить все записи, чтобы увидеть, есть ли в DB-B некоторые недостатки. Если у моей таблицы много записей, это может быть проблемой производительности, не так ли? – ericpap

Вы можете определить фильтр в таблице в репликации, это не проблема. Действительно, этот SP может занять много ресурсов, в зависимости от таблицы и логики. Обычно это не так уж плохо, и мы можем много помочь этому процессу. Мы можем хранить «водяной знак» для таблицы, чтобы проверять только последнюю часть данных, мы можем хранить версию строки в строке для обнаружения обновлений и т. Д. – Alsin

Я не знал, что могу сделать условную репликацию на таблице. Это может быть очень хорошим решением. Но как я могу управлять основным ключом в этих случаях? Одна и та же запись из DB-A может иметь различный идентификатор на DB-B, или я ошибаюсь? – ericpap

Generic Insert Trigger

ответ

Смежные вопросы