Куда пихать бизнес-логику? Кажется, что ответ...

Куда пихать бизнес-логику?

Кажется, что ответ очевиден: бизнес-логика должна жить в коде. Но бывает, что приложение начинает тратить кучу времени на перегон данных по сети, и при этом страдает согласованность данных. Тогда возникает соблазн использовать триггеры. Они автоматически срабатывают при выполнении какого-то действия в базе Виды событий, которые могут запустить триггер: DML (вставка, изменение, удаление строки) DDL (вставка, изменение, удаление какого-нибудь объекта, например, таблицы) Системные (например, LOGON, STARTUP) Частота запуска: FOR EACH ROW (на каждую строку) FOR EACH STATEMENT (один раз на всю команду) Момент срабатывания: BEFORE (до выполнения операции, возможно изменить значения) AFTER (после операции, когда данные уже записаны, но транзакция не завершена) INSTEAD OF (вместо операции) Почему триггеров надо бояться, как огня? Триггер это мощный, но крайне опасный инструмент: 🔥 Триггер вызывается внутри транзакции и замедляет ее. Внедрение триггеров может снизить производительность в десятки раз 🔥 Поэтому, если в триггере произошла ошибка, случится полный откат (в том числе того действия, которое вызвало триггер) 🔥 Порядок срабатывания нескольких триггеров одного типа на одно событие случаен 🔥Триггер может изменить данные, которые вызовут срабатывание других триггеров. Неконтролируемая каскадная цепочка способна положить сервер 🔥 Если триггер А меняет таблицу Б, на которой висит триггер Б, который меняет таблицу А… Всё падает в рекурсию ‼️ А в Oracle построчный триггер ещё и не может работать с таблицей, на которой он сработал. Системный аналитик должен учитывать эту особенность при написании ТЗ