NoSQL в SQL Server

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

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

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

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

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

28 голосов | спросил Andy Clark 30 MarpmMon, 30 Mar 2015 17:21:24 +03002015-03-30T17:21:24+03:0005 2015, 17:21:24

2 ответа


73
  

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

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

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

ответил Mason Wheeler 30 MarpmMon, 30 Mar 2015 17:41:06 +03002015-03-30T17:41:06+03:0005 2015, 17:41:06
3
  

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

     

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

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

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

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


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

  

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

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

  

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

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


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

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

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

ответил Paul Draper 30 MarpmMon, 30 Mar 2015 23:00:56 +03002015-03-30T23:00:56+03:0011 2015, 23:00:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132