Целостность БД: триггер против ключей / ограничений

Question

Я и мой друг спорили друг с другом о дизайне базы данных.
Он утверждает, что для обеспечения целостности сложной базы данных лучше использовать триггеры.

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

Что вы думаете об этом?

Answer 1

"Вот обсуждение AskTom по этой теме. Не существует жесткого и быстрого правила по этому вопросу (иначе не было бы дебатов!) ..."

Да, есть. Декларативный всегда лучше, чем в процедурном отношении. Декларативный менее подвержен ошибкам. Декларативный легче поддерживать. Декларативный - больше самодокументируемый, чем процедурно осуществленный. Декларативный предоставляет лучший повод для оптимизации СУБД, а СУБД - это лучший оптимизатор, чем программист, в большинстве случаев.

Единственное преимущество, реализованное процедурно, заключается в том, что оно означает задания для тех, у кого их не было бы, если бы были доступны истинные декларативные ограничения, а не только плохие PK + FK, которые мы получаем из SQL.

Answer 2

Вы на самом деле не говорите, почему ваш друг думает так, как думает, но в любом случае ограничения / ключи являются стандартным, определенным и надлежащим способом обеспечения целостности данных по двум причинам:

• Все их знают, и вы избежите нарушения принципа наименьшего удивления, используя их.

• Они уже внедрены, проверены и работают.

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

Answer 3

Вы не указали, какая база данных, но я предполагаю стандартную реляционную СУБД ANSI, такую ​​как Oracle или SQL Server.

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

Если ваш RI более сложный, например, если поле 1 в родительской записи> 100, тогда поле 2 в дочерней записи должно быть <200. Триггеры должны использоваться. </p>

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

Answer 4

Я не думаю, что это однозначно, так или иначе, но я склонен использовать ограничения DRI для всего, что может быть сделано в ограничении DRI, и сохранять триггеры для тех вещей, которые не могут быть выполнены в ограничении DRI (например, предотвращение перекрытия диапазонов дат)