Обеспечение ссылочной целостности с помощью триггеров вместо внешних ключей

Question

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

Есть парааспекты дизайна, которые приводят меня к написанию триггеров для выполнения того, что обычно делают FK:

1. В некоторых частях модели используется шаблон наследования таблиц классов и некоторые изТаблицы данных имеют ObjectID, базовый тип которого должен быть ограничен подмножеством типов объектов.Это довольно легко сделать в триггере, но невозможно в FK, не усложняя модель данных.

2. База данных имеет очень гибкую модель справочных данных, которая позволяет конечным пользователям настраивать своиэкземпляр базы данных (у каждого клиента будет своя собственная база данных) с новыми полями, а также с расширением списка предопределенных значений для общих полей.Сначала у меня было сто маленьких таблиц с одинаковой схемой (ID, Name), но с тех пор я объединил их в одну таблицу (FieldID, ID, Name).Опять же, это было бы довольно просто проверить в триггере, но невозможно в FK

Некоторые другие детали:

• Как упоминалось выше, каждый клиент будетиметь собственную копию базы данных
• Размер каждой базы данных вряд ли будет очень большим.Вероятно, где-то в диапазоне 10 - 50 ГБ
• MS SQL 2008

Звучит ли эта идея разумной?Или есть какие-то огромные подводные камни, о которых я не думаю?Причиной создания внешних ключей является обеспечение целостности данных и предотвращение появления потерянных строк.Пока эта цель достигнута, средства не должны иметь значения, верно?

EDIT : я чувствую, что должен уточнить, что я не собираюсь выполнять ВСЕ проверки ссылочной целостности с помощью триггеров.Когда я смогу, я буду использовать внешний ключ.В моей модели есть пара областей, где я не могу.Я ценю вдумчивые ответы до сих пор.

Answer 1

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

Мне приходилось поддерживать такую ​​схему данных ObjectId в моей карьере, и мой опыт работы с ней всегда был отрицательным. С течением времени обслуживание становится очень болезненным и становится очень сложным для выполнения значимых запросов. По сути, вы бы отказались от «реальной» реляционной модели для своего рода модели метаданных.

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

Все это говорит о том, что если бы я собирался пойти по маршруту "ObjectId", я бы подумал о том, чтобы обеспечить целостность на уровне приложения и не использовать триггеры. Недостатком было бы то, что это позволило бы получить неверные данные в системе (логические ошибки или люди, вводящие данные вручную через SSMS). Однако обслуживание, вероятно, будет более управляемым.

Answer 2

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

Кроме того, что касается внешних ключей, я нашел это ...

причины определения внешнего ключа ограничения

• Они физически определяют бизнес, предотвращая проблемы целостности данных в ваша база данных. (например, база данных предотвращает создание позиций без существующего заголовка заказа)
• Они логически документируют бизнес, показывая, как все данные относятся к друг с другом. Для кого-то нового для вас организация, это позволяет ему / ей получить хорошее понимание того, как бизнес работает. (например, каждый заказ принято иметь действующего клиента назначен)
• Внешние ключи являются встроенными в SQL Server и предназначены для предотвращения проблемы целостности данных. Бизнес логика разработчики не должны быть в дело проверочной таблицы отношения.
• Если они определены и проиндексированы правильно, они могут быть использованы SQL Серверная система запросов для генерации чрезвычайно эффективные планы запросов.

от http://www.mssqltips.com/tip.asp?tip=1296

Answer 3

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

Вы должны изучить NoSQL и структурированное хранилище данных.

Answer 4

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

Хотя клиенты настраивают свою структуру базы данных, возникают проблемы.Это может вызвать проблемы с техническим обслуживанием в будущем.Лучшим вариантом является создание универсальной структуры, которая может содержать любые данные, например, таблицу пар ключ / значение.