Профессионалы таблиц истории, недостатки и глюки - использующие триггеры, sproc или на [закрытом] прикладном уровне

Триггеры - это самый быстрый и простой способ создания простой истории. Следующая информация предполагает более сложный пример, когда обработка истории может включать в себя некоторые бизнес-правила и может потребовать регистрации информации, не найденной в отслеживаемой таблице.

Тем, кто думает, что триггеры безопаснее, чем sprocs, потому что их нельзя обойти, я напоминаю им, что они делают следующее предположение:

!) Существуют разрешения, которые не позволяют пользователям запускать DISABLE TRIGGER [но тогда разрешения тоже могут существовать чтобы ограничить весь доступ к базе данных, за исключением EXECUTE на sprocs, который является обычным шаблоном для корпоративных приложений] - поэтому необходимо предполагать правильные разрешения и, следовательно, sprocs равные триггеры с точки зрения безопасности и возможности обхода

! ) В зависимости от базы данных может быть возможно выполнять операторы обновления, которые не запускают триггеры. Я мог воспользоваться знанием глубины выполнения вложенных триггеров, чтобы обойти триггер. Единственное надежное решение включает безопасность в базе данных и ограничение доступа к данным с использованием только утвержденных механизмов - будь то триггеры, sprocs или уровни доступа к данным.

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

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

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

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

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

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

Триггеры - единственный надежный способ зафиксировать изменения. Если вы делаете это в хранимых процедурах или в приложении, вы всегда можете войти и SQL отменить изменение, для которого у вас нет журнала (непреднамеренно). Конечно, тот, кто не хочет выходить из журнала, может отключить триггеры. Но лучше заставить кого-нибудь отключить ведение журнала, чем надеяться, что они его не забудут.