Каковы риски для входа между базами данных через триггер?

Question

Я искал это онлайн и получил смешанные или неясные ответы.

В SQL Server 2005 в настоящее время мы регистрируем некоторые изменения таблиц с помощью триггеров, используя вставленные / удаленные таблицы. В настоящее время наши таблицы журналов существуют в той же базе данных, что и основные таблицы, и я подумал, что с точки зрения управления перемещение таблиц журналов в другую базу данных имеет свои преимущества. По крайней мере, таблицы журналов имеют тенденцию к увеличению в 10 раз для исходной таблицы, поэтому управление различными типами таблиц происходит по разным путям, и разделение их на db может быть полезным.

Если мы пойдем по этому пути, триггер должен войти через границы БД (хотя тот же сервер). Какие проблемы это создаст, чего у меня сейчас нет?

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

Есть ли другие риски?

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

Answer 1

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

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