NoSQL в SQL Server

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

Мы начали новый проект с нуля, используя сначала MVC5, код Entity Framework 6 и SQL Server 2008. Когда архитектор рассмотрел схему базы данных, было заявлено, что все внешние ключи и другие подобные ограничения должны быть удалены, поскольку это «бизнес-логика» и следует применять в рамках бизнес-уровня кода приложения.

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

Вторым аргументом является цель - принять NoSQL-подход к данным. Я обнаружил, что это действительно необычно и неортодоксально: учитывая использование SQL-Server 2008, необходимость создания отчетов, данные, не масштабируемые до терабайт, и отсутствие внимания к таким технологиям, как Mongo, Raven и т. Д.

Кто-нибудь сталкивался с таким сценарием раньше? Зачем кому-то применять NoSQL-подход в SQL Server, предназначенном для ссылочных данных, и не хотеть внешних ключей?

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

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

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

У меня еще есть причина для создания внешнего ключа

- Джоэл Спольски

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

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

Смотрите также Что не так с внешними ключами?

Но они не соответствуют причинам в вашем вопросе.

Это бизнес-логика и должна применяться на бизнес-уровне.

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

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

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

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

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

PS Если вы решите, что вам не нужны внешние ключи, все равно можно использовать реляционную базу данных. Как обобщение, реляционные базы данных более развиты, чем их аналоги в NoSQL. Будучи одним узлом, они могут быть даже быстрее , и поверх них может быть построена абстракция NoSQL .