Чи слід визначати співвідношення між таблицями в базі даних або просто в коді?

На мій досвід, багато проектів, про які я читав у минулому, не мали визначення баз даних у базі даних, натомість вони визначали їх лише у вихідному коді. Тож мені цікаво, які переваги / недоліки визначають співвідношення між таблицями в базі даних та вихідним кодом? І більш широке питання стосується інших вдосконалених функцій сучасних баз даних, таких як каскад, тригери, процедури ... У моїх думках є деякі моменти:

У базі даних:

• Правильні дані з дизайну. Попередити помилки програми, які можуть спричинити недійсні дані.

• Скорочуйте зворотну поїздку в мережу до програми під час вставки / оновлення даних, оскільки програма повинна зробити більше запитів, щоб перевірити цілісність даних.

У вихідному коді:

• Більш гнучка.

• Краще під час масштабування до декількох баз даних, так як іноді це відношення може бути міжбазовим.

• Більше контролю над цілісністю даних. База даних не повинна перевіряти кожен раз, коли програма змінює дані (складність може бути O (n) або O (n log n) (?)). Натомість делегується додатку. І я думаю, що обробка цілісності даних у додатку призведе до більш детальних повідомлень про помилки, ніж використання бази даних. Наприклад, коли ви створюєте сервер API, якщо ви визначаєте відносини в базі даних, а щось піде не так (як, наприклад, посилання, яке не використовується), ви отримаєте виняток SQL з повідомленням. Найпростішим способом буде повернути клієнту 500, що існує "внутрішня помилка сервера", і клієнт не матиме уявлення про те, що йде не так. Або сервер може проаналізувати повідомлення, щоб зрозуміти, що не так, що на мою думку - це некрасивий спосіб, схильний до помилок. Якщо ви дозволите програмі це впоратися,

Є ще щось?

Редагувати: як вказує Кіліан, мій погляд на ефективність та цілісність даних дуже помилковий. Тому я змінив, щоб виправити свою думку там. Я цілком розумію, що дозволити базі даних обробляти це буде більш ефективним та надійним підходом. Будь ласка, перевірте оновлене запитання та дайте кілька питань щодо нього.

Редагувати: дякую всім Усі відповіді, які я отримав, вказують, що обмеження / відносини слід визначати в базі даних. :). У мене є ще одне запитання, оскільки це зовсім поза сферою цього питання, я щойно опублікував це як окреме питання: Обробляти помилку бази даних для сервера API . Будь ласка, залиште трохи інформації.

TL; DR: Обмеження відносин повинні знаходитися в базі даних.

Ваша заявка недостатньо велика.

Ви дійсно правильні, що примусові відносини в базі даних можуть зажадати їх застосування у програмі.

Однак я зазначу, що спочатку слід перевірити документацію програмного забезпечення, яке ви використовуєте, та перевірити існуючі пропозиції товарів. Наприклад, є пропозиції кластеризації поверх Postgres та MySQL.

І навіть якщо вам потрібно мати певну перевірку в додатку, не кидайте дитину разом з водою з ванни . Зрештою, чим менше треба робити, тим краще тобі.

Нарешті, якщо ви переживаєте з приводу майбутніх проблем масштабування, я боюся, що вашій програмі доведеться зазнати значних змін, перш ніж вона все-таки зможе масштабуватися. Як правило, кожен раз, коли ви росте 10 разів, вам доведеться переробляти дизайн… тому не давайте занурювати занадто багато грошей, щоб не передбачити проблеми масштабування, а замість цього використовуйте гроші, щоб насправді дійти до тієї точки, де у вас є ці проблеми.

Ваша заявка недостатньо правильна.

Який шанс, що база даних, яку ви використовуєте, має помильну реалізацію перевірки порівняно з ймовірністю того, що ваша програма має помилкову реалізацію чека?

І кого ви змінюєте найчастіше?

Я б зробив ставку на правильність бази даних у будь-який час .

Ваші розробники роздумують недостатньо.

Зменшіть мережеву зворотну поїздку до програми, коли вставляти / оновлювати дані, оскільки програма повинна робити більше запитів, щоб перевірити цілісність даних.

Червоний прапор ! ¹

Якщо ви думаєте:

• перевірити, чи існує запис
• якщо ні, вставте запис

то ви провалили найпростішу проблему одночасності: інший процес / нитка може додавати запис під час проходження.

Якщо ви думаєте:

• перевірити, чи існує запис
• якщо ні, вставте запис
• перевірте, чи запис було вставлено як дублікат

тоді ви не змогли обліковувати MVCC: перегляд наявної бази даних є знімком на момент початку вашої транзакції; він не показує всіх оновлень, які відбуваються, а може бути, навіть не здійснюються.

Підтримання обмежень на декількох сесіях - це справді важка проблема, радий, що це вирішено у вашій базі даних.

¹ Якщо ваша база даних належним чином не реалізує властивість Serializable; але мало хто насправді це робить.

Останнє:

І я думаю, обробка цілісності даних у застосуванні дозволить отримати більш багатослівне повідомлення про помилку, ніж використання бази даних. Наприклад, коли ви створюєте сервер API. Якщо ви визначите відносини в базі даних, і щось піде не так (як-от посилання, що посилається, не існує), ви отримаєте виняток SQL з повідомленням.

Не розбирайте повідомлення про помилки , якщо ви використовуєте будь-яку базу даних виробничого класу, вона повинна повертати структуровані помилки. У вас буде якийсь код помилки, принаймні, щоб вказати, що можливо неправильно, і на основі цього коду ви можете створити відповідне повідомлення про помилку.

Зауважте, що в більшості випадків цього коду вистачає: якщо у вас є код помилки, який повідомляє про те, що посилання на зовнішній ключ не існує, можливо, у цій таблиці є лише один зовнішній ключ, тож ви знаєте в коді, в чому проблема .

Крім того, і будьмо чесними тут, більшість випадків ви все одно не будете обробляти помилки, які витончено. Просто тому, що їх так багато, і ви не будете рахувати за них усіх ...

... що просто прив'язується до точки правильності вище. Щоразу, коли ви бачите "500: внутрішня помилка сервера", оскільки обмеження бази даних спрацьовувало і не оброблялося, це означає, що база даних зберегла вас, оскільки ви просто забули обробляти її в коді.

Базі даних не потрібно перевіряти цілісність даних щоразу, коли додаток змінює дані.

Це глибоко помилковий момент. Бази даних були створені саме для цієї мети. Якщо вам потрібні перевірки цілісності даних (і якщо ви думаєте, що вони вам не потрібні, ви, мабуть, помиляєтеся), то дозволяти базі даних обробляти їх майже напевно є більш ефективною і менш схильною до помилок, ніж робити це в логіці програми.

Обмеження повинні лежати у вашій базі даних, оскільки (з найкращою волею у світі) ваш додаток не буде єдиним, що коли-небудь має доступ до цієї бази даних.

У якийсь момент може знадобитися виправлення сценарію в базі даних, або вам може знадобитися перемістити дані з однієї таблиці в іншу при розгортанні.

Крім того, ви можете отримати інші вимоги, наприклад, "Big customer X дійсно потребує цього листа Excel, імпортованого в нашу базу даних сьогодні в другій половині дня", де вам не припаде до розкоші адаптувати ваш код програми до відповідного випадку, коли брудний SQL-скрипт виконає це вчасно.

Тут цілісність рівня бази даних врятує ваш бекон.

Крім того, сформулюйте розробника, який приймає вашу роль у цій компанії після того, як ви виїдете, а потім покладіть на нього завдання внести зміни в базу даних.

Чи ненавидить він вас, якщо в базі даних немає обмежень ФК, щоб він міг сказати, які стосунки має таблиця, перш ніж змінити її? ( Підказка, відповідь - так )

Ви повинні мати відносини в базі даних.

Як зазначається в іншій відповіді, виконання перевірки обмежень буде набагато кращою у цій базі даних, ніж всередині вашої програми. Перевірки обмежень в базі даних є однією з речей, в яких добре використовуються бази даних.

Якщо вам коли-небудь потрібна додаткова гнучкість - наприклад, ваші помічені посилання на міжбанківські бази даних - ви можете усунути обмеження навмисно та з урахуванням. Послідовність у вашій базі даних означає, що ви можете змінити ці обмеження та визначеність референтної цілісності.

• Ми більше не живемо в одному задньому <-> одному передньому світі.
• Більшість рішень стосуються веб-інтерфейсу, мобільного фронтального пристрою, пакетного фронтального пристрою та фронтального пристрою iPad тощо.
• Двигуни бази даних вже мають тисячі випробуваних рядків коду, оптимізованих для забезпечення референтної цілісності.

Чи дійсно ви можете дозволити собі написання та тестування референційного коду, що підтверджує цілісність, коли у вас є код вирішення проблем домену?

Якщо ви не підтверджуєте цілісність даних, обмеження, стосунки тощо на рівні бази даних, це означає, що людям, які мають доступ до бази даних виробництва (через будь-який інший клієнт, включаючи інструмент доступу до БД), зіпсувати ваші дані набагато простіше.

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

В якості додаткового зауваження до цього, спроектуйте свою базу даних максимально нормалізованою та атомною. Ніяких «божих» таблиць. Витратьте багато зусиль на розробку вашої бази даних як можна простіше, в ідеалі з багатьма невеликими таблицями, які окремо дуже чітко визначені, з однозначною відповідальністю і ретельно перевірені у всіх стовпцях. База даних є останнім захисником вашої цілісності даних. Він являє собою утримання замку.

Більшість людей в основному говорять «так, в загальному ти будеш завжди визначати відносини в базі даних». Але якби дисципліни з інформатики були такими простими, нас називали б "Програмними читачами", а не "Інженерами програмного забезпечення". Я дійсно погоджуюся з тим, що обмеження повинні міститись у базі даних, якщо тільки немає вагомих причин вони не повинні , тому дозвольте лише навести пару причин, які можуть вважатися хорошими в певних ситуаціях:

Дублікат коду

Іноді в коді програми буде існувати певна кількість функціональних можливостей, якими може оброблятися база даних. Якщо додати в базу даних щось на зразок обмежень, було б зайвим, можливо, краще не дублювати функціональність, оскільки ви порушуєте принципи DRY, і ви можете погіршити акт жонглювання синхронізацією бази даних та коду програми.

Зусилля

Якщо ваша база даних вже робить те, що потрібно робити, не використовуючи розширених функцій, можливо, ви хочете оцінити, куди слід розмістити свій час, гроші та зусилля. Якщо додавання обмежень дозволить запобігти катастрофічній невдачі і, таким чином, заощадити вашій компанії багато грошей, то, мабуть, того варто. Якщо ви додаєте обмеження, які повинні містити, але вже гарантовано ніколи не будуть порушені, ви витрачаєте час і забруднюєте свою кодову базу. Тут гарантоване слово оперативне.

Ефективність

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

Контроль

Дещо пов'язане з ефективністю. Іноді потрібен надзвичайно тонкий контроль над тим, як функція реалізована, а іноді, маючи обробку бази даних, вона ховає її за чорною скринькою, яку потрібно відкрити.

Точки закриття

• Бази даних записуються в код. У них немає нічого магічного, що ви не можете зробити у власному коді.
• Нічого не вільне. Обмеження, відносини тощо використовують усі цикли процесора.
• Люди у світі NoSQL чудово уживаються без традиційних реляційних функцій. Наприклад, у MongoDB структура документів JSON є достатньою для підтримки всієї бази даних.
• Сліпе і необізнане використання розширених функцій бази даних не може гарантувати жодних переваг. Ви можете випадково змусити щось зробити, лише щоб потім його зламати.
• Ви задали дуже загальне запитання, не перераховуючи конкретні вимоги чи обмеження. Справжня відповідь на ваше запитання - це "залежить".
• Ви не вказали, чи це проблема в масштабі підприємства. Інші відповіді говорять про такі речі, як клієнти та цілісність даних, але іноді ці речі не важливі.
• Я припускаю, що ви говорите про традиційну реляційну базу даних SQL.
• Моя точка зору полягає в тому, що я відмовився від використання тонни обмежень та сторонніх ключів у невеликих (до 50 таблиць) проектах, і не помітив будь-яких недоліків .

Останнє, що я скажу, це те, що ви дізнаєтесь, чи не слід розміщувати функціональні можливості в базі даних. Якщо ви не впевнені, вам, мабуть, краще скористатися функціями бази даних, оскільки вони зазвичай працюють дуже добре.

Як завжди, відповідей багато. Для мене я знайшов просте правило (ну воно працює лише для орієнтованого на модель підходу). Зазвичай я зосереджуюсь лише на різних шарах програм.

Якщо модель складається з декількох сутностей і існують залежності між сутностями, шар стійкості повинен відображати ці залежності з його можливостями. Отже, якщо ви використовуєте RDBMS, вам також слід використовувати зовнішні ключі. Причина проста. Таким чином, дані завжди справедливі структурно.

Будь-який примірник, який працює над цим шаром стійкості, може покластися на нього. Я припускаю, що ви інкапсулюєте цей шар через інтерфейс (сервіс). Тож ось момент, коли дизайн закінчується і починається реальний світ.

Дивлячись на ваші моменти, особливо на крос-бази даних . У такому випадку, так, не повинно бути посилання, реалізоване в самому RDBMS, а в службі. Але перш ніж слідувати цим способом, чи не було б краще розглянути це вже під час проектування?

Значить, якщо я вже знаю, що є частини, які потрібно зберігати в іншій БД, то я можу розмістити їх уже там і визначити його як окрему модель. Правильно?

Ви також вказуєте, що реалізація цього коду є більш гнучким . Правильно, але це не здається, що ви маєте справу з незавершеним дизайном? Запитайте себе: навіщо вам потрібна більша гнучкість?

Проблема продуктивності через перевірку цілісності в БД не реальна. RDBMS може перевірити такі речі набагато швидше, ніж будь-яка реалізована вами реалізація. Чому? Ну, вам доведеться мати справу зі зривами засобів масової інформації, RDBMS не робить. І він може оптимізувати такі перевірки, використовуючи свою статистику aso

Отже, бачите, все повертається до дизайну. Звичайно, ви можете сказати зараз, але що робити, якщо з’явиться невідома вимога, зміна гри? Так, це може статися, але такі зміни повинні бути розроблені та сплановані як і раніше. ; o)

У вас є дуже хороші відповіді, але ще кілька моментів

Цілісність даних - це те, що створена база даних

Виконання належної одночасності, як видалення FK, на рівні програми було б жахливо

Експертиза цілісності даних проводиться за допомогою DBA

На програмному рівні ви вставляєте, оновлюєте, об'ємне оновлення, групове вставлення, групове видалення ...
Тонкий клієнт, товстий клієнт, мобільний клієнт ....
Цілісність даних - це не досвід роботи програміста - багато дублікату коду, і хтось зіпсує це вгору

Скажімо, вас зламають - у будь-якому випадку ви потрапляєте в халепу, але хакер може завдати великої шкоди через невеликий отвір, якщо в базі даних немає захисту цілісності

Можливо, вам потрібно буде маніпулювати даними безпосередньо через SQL або TSQL
Ніхто не пам’ятатиме всі правила даних

Ваше питання не має сенсу: якщо ви можете змінити базу даних, це код, якщо ви не можете змінити базу даних, вам доведеться створити свої обмеження в іншому місці.

База даних, яку ви можете змінити, - це кожний біт, стільки ж коду, скільки будь-яка лінія ruby, javascript, c # або ada.

Питання про те, де поставити обмеження у вашій системі, має зводитися до надійності, вартості та простоти розробки.

Тут є багато хороших відповідей. Додам, що якщо у вас є додаток, написане мовою Y, ви можете створити код, схожий на обмеження бази даних у Y. І тоді хтось захоче отримати доступ до вашої бази даних мовою Z, вам доведеться знову написати той же код. Допоможе вам Бог, якщо реалізації не зовсім однакові. Або коли досвідчений бізнес-користувач підключається до вашої бази даних за допомогою Microsoft Access.

Мій досвід говорить мені, що коли люди не хочуть використовувати обмеження в базі даних, це тому, що вони насправді намагаються зробити щось не так. Наприклад, вони намагаються збільшити дані про завантаження, і вони хочуть на деякий час залишити стовпці, що не входять до нуля. Вони мають намір "виправити це пізніше", оскільки ситуація, яка зробила ненульове обмеження критичною, "в цьому випадку неможливо статися". Інший приклад може бути, коли вони намагаються вбудувати два різних типи даних в одну таблицю.

Більш досвідчені люди зроблять крок назад і знайдуть рішення, яке не передбачає спроб обійти обмеження. Рішення може бути просто тим, що обмеження вже не є правильним, оскільки бізнес, звичайно, змінився.