Тригери SQL і коли або коли їх не використовувати.

Коли я спочатку дізнавався про SQL, мені завжди говорили, використовуйте тригери лише тоді, коли вам дійсно потрібно, і замість цього, якщо можливо, скористайтеся збереженими процедурами.

На жаль, у той час (добрі кілька років тому) я не був таким цікавим і піклувався про основи, як я зараз, тому ніколи не питав причини, чому.

Яка думка громад у цьому? Це лише чиїсь особисті переваги, чи слід уникати тригерів (як і курсорів), якщо для них немає вагомих причин.

Стаття Вікіпедії про тригери баз даних дає хороший огляд того, що є тригерами та коли їх використовувати в різних базах даних.

Наступне обговорення базується лише на SQL Server.

Використання тригерів цілком справедливо, коли їх використання виправдане. Наприклад, вони мають хороше значення для аудиту (зберігання історії даних), не вимагаючи явного процесуального коду з кожною командою CRUD у кожній таблиці.

Тригери дають вам контроль безпосередньо перед зміною даних та безпосередньо після зміни даних. Це дозволяє:

• Аудит, як згадувалося раніше
• Перевірка та перевірка безпеки бізнесу, якщо так бажано. Через такий тип управління ви можете виконувати такі завдання, як форматування стовпців до і після вставок у базу даних.

Мені завжди говорили: використовуйте тригери лише тоді, коли вам справді потрібно, а замість цього, якщо можливо, вибирайте використовувати збережені процедури.

Причинами цього можуть бути:

1. Деякі функції, які раніше спрацьовували, можна було виконувати іншими способами, такими як оновлення підсумків та автоматичний обчислення на стовпчику.
2. Ви не бачите, куди викликається тригер, досліджуючи код, не знаючи, чи існує. Ви бачите їх дію, коли бачите зміни даних, і іноді спантеличено з'ясувати, чому зміни відбулися, якщо ви не знаєте, що на таблиці (их) діє тригер або більше.
3. Якщо ви використовуєте кілька елементів управління базами даних, таких як CHECK, RI, Triggers на декількох таблицях, детальний потік транзакцій стає складним для розуміння та підтримки. Вам потрібно буде точно знати, що відбувається, коли. Знову для цього вам знадобиться хороша документація.

Деякі відмінності між тригерами і незапущеними збереженими процедурами є (серед інших):

• Процедура, що зберігається без тригеру, - це як програма, на яку явно потрібно викликати код або планувальник, або пакетне завдання тощо, щоб виконати свою роботу, тоді як тригер aa - це особливий тип збереженої процедури, яка спрацьовує як відповідь на подію, а не бути безпосередньо виконаною користувачем. Наприклад, подія може бути зміною даних у стовпці даних.
• Тригери мають типи. Тригери DDL та тригери DML (типів: INSTEAD OF, For і AFTER)
• Процедури, які не тригерують, можуть зберігати будь-який тип об'єкта, однак для посилання на подання ви повинні використовувати INSTEAD OF тригери.
• У SQLServer ви можете мати будь-яке число у не тригерних збережених процедурах, але лише 1 ВСТАНОВКА тригера на таблицю.

Тригери є вимогою до будь-яких складних правил цілісності даних. Вони не можуть бути застосовані ніде, крім бази даних, або у вас виникнуть проблеми з цілісністю даних.

Вони також є найкращим місцем для аудиту, якщо ви не хочете зафіксувати всі зміни в базі даних (що є проблемою аудиту в додатку).

Тригери можуть спричинити проблеми з продуктивністю, якщо вони не написані ретельно і недостатньо знають розробники, щоб їх добре написати. Це частина, де вони отримують свій поганий реп.

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

Неважко писати погані тригери, які роблять дурні речі, як-от намагаються надсилати електронні листи. Ви дійсно хочете не мати можливості змінювати записи в db, якщо сервер електронної пошти знижується?

На сервері SQL тригери працюють на групі записів. Надто часто розробники думають, що їм потрібно обробляти лише одну вставку, оновлення або видалення записів. Це не єдиний вид змін даних, які відбуваються з базою даних, і всі тригери повинні бути протестовані в умовах зміни 1 запису та багатьох змін записів. Забуття провести другий тест може призвести до надзвичайно погано працюючих тригерів або втрати цілісності даних.

Використання тригерів бази даних

1. Автоматичне керування значеннями стовпців.
2. Для забезпечення складних обмежень цілісності.
3. Дотримуватись складних правил бізнесу.
4. Налаштування складних авторизацій безпеки.
5. Для підтримки реплікаційних таблиць.
6. Для аудиту зміни даних.

Ще один випадок використання, до якого я особисто натрапив, - це бази даних, до яких звертається більше ніж одна програма. Якщо ви хочете реалізувати функціональність, але не переробити всі системи для цього, тригер робить розумне рішення.

Наприклад, я нещодавно працював над базою даних, яка раніше існувала як виключно офісна система. Коли для інтерфейсу з ним було написано веб-сайт, ми хотіли впровадити систему сповіщень (подібну, наприклад, до stackexchange), яка запускалася б за допомогою багатьох подій, таких як обробка транзакції тощо. Нам вдалося реалізувати тригер, щоб оновлення в сервісному вікні офісу запустили тригер, щоб створити сповіщення для інтерфейсу та повідомити користувачеві, що їх транзакція була оброблена офісом.

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

Скажімо, вам потрібно перенести дані до сторонньої системи майже в режимі реального часу. Ваша таблиця містить 950 гігабайт даних, тому вона занадто велика, щоб просто просто просунути всю таблицю до стороннього додатку.

Натомість ви накопичуєте зміни в черзі. Потім деякі зовнішні програми періодично виштовхуватимуть невеликі партії даних з черги.

Система має понад 2000 збережених процедур. Ви також знаєте, що тонни sql існують у вихідному коді. Щоб гарантувати правильність заповнення черги, вам доведеться шукати всі збережені програми та код і сподіваєтесь, що ви нічого не пропустите.

Натомість ви можете поставити тригер на стіл, щоб тримати чергу оновленою. Гарантовано нічого не пропустіть. Одне центральне місце. Виконання штрафу? Насправді не тому, що потрапляння по черзі не можна уникнути, чи то тригером, чи зовнішнім.

У цьому сценарії я б сказав, що не використовувати тригер - це поганий вибір дизайну. Якщо пізніше ви хочете скористатися новим методом передачі даних (скажімо, черга не працює) і інтерфейс зміниться, ви захищені, якщо використовувати тригер. Тригери часто є найкращим вибором. Не слухайте догматичних фан-бойок.

Тригер, який надсилає електронну пошту, не обов'язково є дурною ідеєю. Що нерозумно - це не передбачити відключення електронної пошти в дизайні та поводження з ним витончено без втрати даних. «Дурна» частина цього насправді погана для неіснуючих помилок з обробкою лінивих розробників, які відчувають, що вони не застраховані від помилок.

Я б також запропонував зауважити, що тригер може бути простим, викликаючи збережену процедуру / функцію, яка може бути довільно складною та може бути повторно використана за допомогою декількох тригерів або інших збережених процедур. Ось чому є пакети та бібліотеки.

Фанатизм справді калічить.