[СУБД] Триггеры

Почему только логгирование? Бизнес логика же.

На ум приходит создание каких-то искусственных ограничений при внесении изменений. Например, чтобы какие-то данные в базе изменялись не чаще определенного интервала времени. Хотя такое, наверное, редко надо.

Обычно хитроумная бизнес логика.

А вычисляемые поля могут быть реализованы View.

Во view ты можешь использовать только SQL, который не всегда удобен. Но триггеры нужны не только для замены view'ов. А вообще не парься, если тебе вдруг понадобятся триггеры, ты это сразу поймёшь.

Например, в Oracle с помощью триггеров реализуется авто-инкремент

Сразу видно, что ты быдлокодер на мускуле или типа того.
И да, все отписались для чего это надо

Много лет назад делал для IPB nntp-гейт. На php-код нормально сесть было нельзя. Пришлось навесить триггеров и процедур, чтобы вели дополнительные таблицы с индексами сообщений. Другого выхода не было.

тривиальный пример: есть таблица продажи(дата_время, продавец, товар, сумма), надо сделать чтобы в таблице продажи_за_неделю(неделя, сумма) всегда были актуальные данные

>>Например, в Oracle с помощью триггеров реализуется авто-инкремент

Кстати, если не ошибаюсь, в Firebird была похожая ситуация.

>тривиальный пример: есть таблица продажи(дата_время, продавец, товар, сумма), надо сделать чтобы в таблице продажи_за_неделю(неделя, сумма) всегда были актуальные данные
Почему не view? А если магазин большой и продажи (добавление в таблицу продажи) происходят чаще, чем просмотр продаж_за_неделю?

Вью не всегда оптимально...
Ну вот тебе пример, ты делаешь удаление записи (к примеру, чей-то пост), а триггер у тебя автоматом снимает скор пользователям-участникам.

> Почему не view? А если магазин большой и продажи (добавление в таблицу продажи) происходят чаще, чем просмотр продаж_за_неделю?

очевидно, что 1 просмотр таблицы продаж_за_неделю сделает (приблизительно) столько же работы, сколько все триггеры (да еще и диском придется пошуршать, в то время как при работе триггера данные уже в оперативке)

при 100 просмотрах таблицы продаж_за_неделю экономия уже в 100 раз

*особенно* если магазин большой.

а можно использовать материализованную вьюшку
(если они поддерживаются, конечно..)

>пример, ты делаешь удаление записи (к примеру, чей-то пост), а триггер у тебя автоматом снимает скор пользователям

А потом кто-то решает почистить старъё, и у всех старых и активных пользователей наступает банный день.

Это был пример бизнес логики и триггеры в большинстве СУБД вещь включаемая - выключаемая. Вообще холиваров о применении бизнес логики в дб не меньше чем вин/лин.

Открываем доку на oracle и читаем (не привел остальные пункты для чего не надо их делать):
Use triggers to guarantee that when a specific operation is performed, related actions are performed.
Use triggers only for centralized, global operations that should be fired for the triggering statement, regardless of which user or database application issues the statement.

>На ум приходит только логгирование изменений в БД.

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

неудачный пример использования триггеров на логировании.

и да, примеров использования триггеров мульён, что даже глупо спрашивать про это. вот ты сидя на горшке после акта дефикации автоматом за бумажкой тянешься? :) вот это и есть триггер - случилось событие, запустилось какое-то действие.