Каковы риски для входа между базами данных через триггер?
Я искал это онлайн и получил смешанные или неясные ответы.
В SQL Server 2005 в настоящее время мы регистрируем некоторые изменения таблиц с помощью триггеров, используя вставленные / удаленные таблицы. В настоящее время наши таблицы журналов существуют в той же базе данных, что и основные таблицы, и я подумал, что с точки зрения управления перемещение таблиц журналов в другую базу данных имеет свои преимущества. По крайней мере, таблицы журналов имеют тенденцию к росту в 10 раз для исходной таблицы, поэтому управление различными типами таблиц осуществляется по разным путям, и разделение их на db может быть полезным.
Если мы пойдем по этому пути, триггер должен войти через границы БД (хотя тот же сервер). Какие проблемы это создаст, чего у меня сейчас нет?
Пока что основным кажется то, что кто-то может снять базу данных независимо от другого (редко), и тогда запись будет потеряна, а вставка будет сохранена, или вставки не будут выполнены, потому что триггер не работает, в зависимости от того, как триггер был написан.
Есть ли другие риски?
Другое решение, которое было предложено, состояло в том, чтобы войти в тот же самый DB и иметь задание переместить (удалить и скопировать) записи в другой DB. Тем не менее, я до сих пор не знаю, почему это лучшее решение.
1 ответ
Триггеры имеют все недостатки, которые вы описываете. В частности, если база данных, предназначенная для получения журналов, оказывается неработоспособной, вы не только теряете ведение журнала, но и любой запрос, который генерирует запись журнала, завершится неудачей, если триггер не будет тщательно написан, чтобы избежать этого. Использование периодического задания для копирования данных журнала в принимающую базу данных не имеет такого недостатка; если принимающая база данных не работает, то вы не потеряете журналы (потому что они все еще находятся в исходной базе данных, ожидающих копирования), и вам также не нужно беспокоиться о неудачной регистрации, приводящей к сбою запросов.
Делали ли вы какие-либо сравнительные тесты, чтобы подтвердить, действительно ли такое решение действительно необходимо? Вам не хватает диска или каким-либо иным образом ограничены таким образом, что дополнительные усилия и сложность записи в отдельную базу данных оправдывают себя?