Должна ли обеспечиваться ссылочная целостность?

Предположение об эффективности, на котором основан вопрос, неверно как общее правило. Обычно, если вам требуется принудительное использование RI, то база данных - это наиболее эффективное место, а НЕ приложение - в противном случае приложение должно запрашивать больше данных, чтобы иметь возможность проверять RI вне базы данных.

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

Наконец, затраты на поддержание ограничений целостности в каждом приложении, как правило, дороже и сложнее, чем делать это один раз в одном месте.

Но полковник Ингус, если у вас есть клиент с идентификатором в сеансе, вы уже исследовали базу данных! Проблема заключается в том, что вы потом пишете свой заказ на продажу, но не прикрепляете его к продукту, потому что не проверяли продукт. Так или иначе, вы получите осиротевшие записи, как в очень большой компании, в которой я сейчас работаю. У нас есть клиенты без истории и без клиентов; клиенты с выдающимся балансом, которые никогда ничего не покупали, и товары, проданные клиентам, которых не существует, - интересные бизнес-концепции - и это заставляет команду очень расстроенных сотрудников службы поддержки работать полный рабочий день, пытаясь разобраться в этом. Было бы гораздо дешевле поставить RI на все и купить большую коробку, чтобы решить любые проблемы с производительностью.

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

Что происходит, когда вы пытаетесь вставить запись в базу данных, и она не справляется со ссылочной целостностью? Вы получаете ошибку из базы данных. Затем вы должны изменить свой код, чтобы он не пытался вставить неверные данные. Чтобы избежать ошибок целостности ссылок, ваш код ДОЛЖЕН знать, какие данные какие. Поэтому ссылочная целостность бесполезна.

Уолтер Митти сказал: «Чтобы проверить ссылочную целостность для новой вставки, вы должны выполнить исследование в базе данных, чтобы убедиться, что ссылка действительна». Вздох ... это полная чушь. Если у меня есть объект Customer в сеансе (это память, то есть RAM для некоторых из вас, ребята), я знаю идентификатор Customer и могу использовать его для вставки объекта SalesOrder. Нет необходимости искать клиента.

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

Пусть выслушает Дэна Притчетта, технического сотрудника eBay, о том, почему определенные конструкции базы данных, такие как транзакции и ссылочная целостность, не являются требованиями, которые учебники могут указать, что они должны быть ... Все сводится к типы данных, объем запросов и бизнес-требования. Уравновесите их, и это приведет вас к прагматическим решениям, а не к догматическим ответам ...

Однако не предполагайте, что сохранение отношений в BLL защитит ваши данные. Вы не можете гарантировать, что будущие разработчики не представят новые API-интерфейсы, которые обходят BLL, по причинам "производительности" или из-за простого непонимания вашей архитектуры ...

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

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

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

Конечно, есть некоторые моменты в другом направлении и причины для создания всего этого вручную - наиболее очевидными являются масштабируемость и производительность. Однако когда / если вы пойдете по этому пути, вы должны знать, от чего вы отказываетесь, чтобы получить такую ​​производительность. В некоторых случаях это выгодный компромисс, но в других случаях это не так, и вам нужна информация, чтобы принять обоснованное решение.

Уже много говорилось о том, что БД должна быть последним местом для проверки/контроля ваших ограничений (и я не могу не согласиться)

Если данные важны, то ваше приложение не будет последним, кто обращается к БД, и не будет единственным.

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

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

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

Кроме того, если другое приложение когда-либо коснется вашей базы данных, оно не обязательно должно следовать (читай: переопределение, возможно, слегка неверно) правилам в вашем BLL. Он может испортить данные, даже если вам каким-то образом удалось стать одним из трех программистов на Земле, написавших код без ошибок.

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

Что сказали paxdiablo и dportas. И мои два цента. Есть еще два соображения.

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

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

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

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