Почему мы не должны включать бизнес-логику в триггеры базы данных?

Question

Деловая сторона моей компании хотела бы реализовать 20 новых триггеров с очень специфичной бизнес-логикой. Они также постоянно возвращаются со старыми изменениями. Логика - это просто групповая структура, зависящая от параметров 99% времени.

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

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

Пока я сказал им:

1. Чрезвычайно высокий риск потери / перезаписи данных
2. Высокая стоимость БД в $
3. Ненужная работа, которую можно автоматизировать с помощью приложения

Есть ли другие пункты, которые можно добавить в этот список?

Извинения, если это не то место, где можно задать этот вопрос.

Спасибо!

1. Чрезвычайно высокий риск потери / перезаписи данных
2. Высокая стоимость БД в $
3. Ненужная работа, которую можно автоматизировать с помощью приложения

Answer 1

Три причины, которые вы назвали, неверны и предают чистую перспективу кодера:

1. Чрезвычайно высокий риск потери / перезаписи данных

   (у вас нет такого риска, если ваши вещи должны быть закодированы на языке, который просто не называется SQL?)

2. Высокая стоимость БД в $

   (у вас нет такого риска, если ваши вещи должны быть закодированы на языке, который просто не называется SQL?)

3. Ненужная работа, которую можно автоматизировать с помощью приложения

   (Автоматизация ваших вещей на языке, который не называется SQL, не является процессом, который включает анализ и написание кода реализации?)

Триггеры являются полезной конструкцией по крайней мере для одной цели: для защиты целостности данных в отношении всех правил целостности, которые не поддерживаются SQL декларативно. Подробные сведения см. В разделе «Продвинутая математика для специалистов по базам данных», глава 11.

Все это говорит: разработчикам следует остерегаться присоединения [выполнения] кода, скажем, к INSERT INTO CUSTOMER по причинам, скажем, «это происходит только в том случае, если мы регистрируем нового клиента, и все новые клиенты должны получать приветственное письмо». (или некоторые такие) ". Предположим, вы захватили другую компанию, и все ее клиенты должны быть интегрированы в вашу базу данных. Уч. Неправильное использование триггеров часто можно проследить до «слишком активного присоединения делового значения к операции БД». Этот конкретный материал действительно принадлежит к той части, где кодируется «бизнес-операция / бизнес-функция», которая может быть кодом приложения или вызываемой хранимой процедурой (отличной от триггеров).

Answer 2

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

1. Триггеры создают риск проблем с производительностью и блокировками. Ничто не мешает вам писать триггеры с ужасными характеристиками производительности или даже более занимательные триггеры, которые запускают другие триггеры, которые запускают оригинальный триггер.

2. Триггеры являются «побочными эффектами», и для большинства людей побочные эффекты часто приводят к ошибкам. Например, если кто-то работает над кодом для сохранения нового бизнес-объекта, и этот код вызывает срабатывание триггера, он может не учитывать это в своем коде и, таким образом, вызывать ошибку.

Если ваш ответ «хорошо, не делайте этого»:

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