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 .