Разработка базы данных: искусство или головная боль (Руководящие отношения)

Я всегда заставляю СУБД применять ограничения по первичному и внешнему ключу; часто я добавляю и проверочные ограничения. Насколько я понимаю, данные слишком важны, чтобы подвергаться риску хранения неточных данных.

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

Почему другие люди не используют ограничения PK, FK и т.д.?

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

Ну, я имею в виду, что каждый имеет право на свое собственное мнение и стратегию развития, но, по моему скромному мнению, эти люди почти наверняка ошибаются :)

Причина, по которой, однако, кто-то может захотеть избежать ограничений, заключается в эффективности. Не потому, что ограничения медленные, а потому, что хранение избыточных данных (т.е. кэширование) - это очень эффективный способ ускорить (ну, или избежать) дорогостоящие вычисления. Это приемлемый подход, если он реализован правильно (т.е. кэш обновляется через регулярные/соответствующие интервалы времени, обычно я делаю это с помощью триггера).

Что касается мотивации не использовать FK без мотивации кэширования, я не могу себе этого представить. Возможно, они стремятся быть "гибкими" в своей структуре БД. Если так, то хорошо, но тогда не используйте реляционную БД, потому что это бессмысленно. Нереляционные СУБД (OO dbs), конечно, имеют свое место, и даже могут быть лучше (довольно спорно, но интересно поспорить), но использовать реляционную СУБД и не использовать ее основные свойства - это ошибка.

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

Есть несколько причин не применять отношения в порядке убывания важности:

1. Удобная для людей обработка ошибок. Ваша программа должна проверять ограничения и посылать пользователю понятное сообщение. По какой-то причине нормальным людям не нравится "SQL exception code -100013 goble rule violated for table gook'.

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

3. Эффективность. Проверка ограничений действительно потребляет IO и CPU.

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

Поскольку ситуация становится более сложной и требуется больше таблиц и взаимосвязей в базе данных, как вы можете гарантировать, что разработчик базы данных не забудет проверить их все? Когда вы вносите изменения в схему, которая добавляет новые «неформальные» отношения, как вы можете гарантировать, что весь код приложения, который может быть затронут, будет изменен?

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

Совершенно безрассудно не устанавливать формально отношения ПК / ФК. Я обрабатываю данные, полученные от разных поставщиков и баз данных. Вы можете сказать, у каких из них есть проблемы с целостностью данных, которые, скорее всего, вызваны неспособностью явно определить отношения из-за низкого качества их данных.

Многие разработчики проверяют ограничения в коде над базой данных, прежде чем фактически приступят к выполнению операции. Иногда это обусловлено соображениями пользовательского опыта (мы не хотим предоставлять пользователям варианты / варианты, которые нельзя сохранить в базе данных). В других случаях это может быть вызвано болью, связанной с выполнением оператора, определением причины сбоя и последующим принятием корректирующих действий. Большинство людей сочли бы код более удобным в обслуживании, если бы он выполнял проверку заранее вместе с другой бизнес-логикой, которая может быть задействована, вместо того, чтобы предпринимать корректирующие действия с помощью обработчика исключений. (Не то чтобы это обязательно идеальный образ мышления, но он преобладает.) В любом случае, если вы выполняете проверку перед выдачей заявления и не особо осознаёте тот факт, что база данных может быть затронута приложений / пользователей, которые не входят через ваш код, обеспечивающий целостность, тогда вы можете сделать вывод, что ограничения базы данных не нужны, особенно с падением производительности, которое может быть понесено в результате их использования. Кроме того, если вы проверяете целостность в коде приложения над базой данных, можно считать нарушением DRY (Don't Repeat Yourself) реализацию логически эквивалентных проверок в самой базе данных. Два проявления правил целостности (в ограничениях базы данных и в коде приложения над базой данных) в принципе могут стать рассинхронизированными, если не будут управляться с осторожностью.

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