Как использовать триггеры базы данных в реальном проекте?

Question

Я много узнал о триггерах и активных базах данных в последних слабостях, но у меня есть несколько вопросов о реальных примерах для них.

На работе мы используем Entity Framework с ASP.Net и MSSQL-сервером. Мы просто используем автоматически сгенерированные ограничения и без триггеров.

Когда я услышал о триггерах, я задал себе следующие вопросы:

1. Какие задачи могут быть выполнены триггерами? например: Генерация отчетных данных: в настоящее время данные для отчетов создаются в vb, но я думаю, что триггер мог бы справиться и с этим. Создание в vb занимает много времени, и пользователю не нужно ждать его, потому что это не нужно для его работы. Это пример идеальной задачи для триггера?

2. Как OR-Mapper обрабатывает манипулируемые данные? например: OR-Mapper распознает, манипулировал ли триггер данными? Платформа сущностей, кажется, кэширует много данных, поэтому я не уверен, что она читает обновленные данные, если триггер манипулирует данными после обработки вставки / обновления / удаления из каркаса.

3. Сколько обработки ограничений должно быть в базе данных? Например: иногда ограничения в базе данных кажутся намного проще и быстрее, чем на уровне выше (vb.net, ...), но как добавить исключения на верхний уровень, которые могут обрабатываться OR-Mapper? Есть ли хорошее решение для обработки исключений SQL (из триггеров) в любом OR-Mapper?

Заранее спасибо

Answer 1

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

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

1. При использовании ORM триггер может быть полезен для некоторых данных, сгенерированных БД, таких как столбцы аудита или пользовательские последовательности значений первичного ключа.
2. Текущие ORM в основном не любят триггеры - они могут реагировать только на изменения в текущей обрабатываемой записи, так что, например, если вы сохраните запись заказа и ваш триггер обновления изменит все упорядоченные элементы, автоматического способа сообщить об этом ORM нет. - вы должны перезагрузить данные вручную. В EF все данные, измененные или сгенерированные в базе данных, должны быть установлены с StoreGeneratedPattern.Identity или StoreGeneratedPattern.Computed - EF полностью следует шаблону, где логика находится либо в базе данных, либо в приложении. После того, как вы определили, что значение назначено в базе данных, вы не сможете изменить его в приложении (оно не будет сохраняться).
3. Логика вашего приложения должна отвечать за проверку данных и сохранение вызовов только в том случае, если проверка прошла успешно. Вам следует избегать ненужных транзакций и обращений к базе данных, если вы заранее знаете, что транзакция завершится неудачей.

Answer 2

Я использую триггеры для двух основных целей: аудит и обновление времени модификации / вставки.При аудите триггеры отправляют данные в связанные таблицы аудита.Это никак не влияет на ORM, так как эти таблицы обычно не отображаются в основном контексте данных (есть отдельный контекст данных аудита, используемый при необходимости просмотра данных аудита).

При записи / изменении вставки/ время модификации, я обычно помечаю эти свойства в модели как [DatabaseGenerated( DatabaseGenerationOptions.Computed )] Это предотвращает сохранение любых значений, установленных в уровне данных, обратно в БД и позволяет триггеру принудительно устанавливать поля DateTime должным образом.

Это не жесткое и быстрое правило, что я управляю аудитом и этими датами таким образом.Иногда мне нужно больше информации аудита, чем доступно в самой базе данных, и вместо этого я выполняю аудит на уровне данных.Иногда я хочу заставить приложение обновлять даты / время (поскольку они могут быть одинаковыми для нескольких строк / таблиц, обновляемых одновременно).В этих случаях я мог бы сделать поле обнуляемым, но [Required] в модели заставило бы установить дату / время, прежде чем модель будет сохранена.

Answer 3

Старый ORM Infomodeler / Visiomodeler (не то, что вы думаете - это было моделирование ролей объектов) предоставлял альтернативу при создании физической модели. Это обеспечило бы всю ссылочную целостность с помощью триггеров. По двум причинам:

1. У некоторых dbmses (особенно Sybase / SQL Server) еще не было декларативного RI, и
2. Это может обеспечить гораздо более мелкозернистую целостность - например, «не более двух детей» или «сыновья или дочери, но не оба» или «обязательный сын или дочь, но не оба».

Таким образом, вызывайте логику, связанную с моделью, так же, как любое ограничение RI. В SQL Server он обрабатывал нарушения с помощью RAISERROR.

Концептуальная проблема с триггерами заключается в том, что они по существу не зависят от контекста - они всегда срабатывают независимо от контекста (по крайней мере, без большой боли, и вам лучше включить их логику в остальную логику, зависящую от контекста). доменные ограничения - единственное место, где я нахожу их полезными, что, как мне кажется, является еще одним общим способом определения «ссылочной целостности».