Целостность ссылочных данных: необходимость, приятное иметь или старая шляпа?

Question

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

Недавний рост популярности баз данных noSQL, таких как MongoDB, Cassandra и т. Д., Изменил подход к передовым методам разработки баз данных еще более радикально.

Мой вопрос: больше нет необходимости ссылочной целостности данных?

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

Насколько необходима ссылочная целостность данных? Может ли кто-нибудь перечислить некоторые проблемы, которые у них были, когда они его не использовали?

Является ли разумной стратегией использование базы данных, такой как PostgreSQL, для более критичных данных и MongoDB для менее критичных, но крайне запрашиваемых данных? Как вы предлагаете точно определить, какие данные являются «критическими», а какие «некритическими»?

Answer 1

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

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

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

Answer 2

Если вы хотите ассоциировать и ссылаться на данные, ссылочная целостность всегда будет иметь значение. Современный вопрос состоит не в том, нужно ли это, а в том, нужно ли управлять им в традиционной манере баз данных sql для проверки полей внешних ключей через индексы, управляемые программистами и администраторами баз данных. Простые базы данных, приспособленные для доступа к объектам, могут скрывать традиционные методы обеспечения целостности данных или могут позволять программно управлять проблемами как исключениями, или такими проблемами можно управлять вручную.

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

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

Answer 3

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

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

Проверьте Django поддержка нескольких баз данных .Имейте в виду, что переход от хранилища данных ACID к хранилищу данных CRUD намного проще, чем наоборот.

Answer 4

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

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

Answer 5

Я работал в компании (ebay.com), где базы данных огромны. Мы не должны использовать какую-либо ссылочную целостность в базе данных. Это ограничение было введено с учетом одного только фактора эффективности. Мы даже не будем ничего определять на уровне ORM (Object Relational Mapping). Все должно быть логически обработано. Я знаю, что это даже сложно представить, но все же это то, что обеспечивает лучшую производительность.

Теперь по вашему вопросу, поскольку на уровне ORM происходит слишком много абстракций, люди даже не заботятся о том, что происходит на стороне базы данных. По крайней мере, новички в коде вряд ли позаботятся о написании триггеров, объявляя ссылочную целостность непосредственно в базе данных (например, oracle), где вы можете многое сделать, написав процедуры хранилища. Но, тем не менее, люди предпочитают и чувствуют, что им легче кодировать все на уровне ORM. Итак, ИМО, я чувствую, что это становится старой шляпой.

Answer 6

Через несколько лет я бы хотел дать свой собственный ответ:

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

Answer 7

В настоящее время ответ на ваш вопрос не является общим, а зависит от приложения и требований бизнеса.

Ответ на ваш вопрос на самом деле: всегда думайте о своей стратегии целостности данных

Например:

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