Обмеження у реляційних базах даних - чому б їх не видалити повністю?

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

Інструменти ORM, такі як EntityContext, Linq2Data, NHibernate, також вирішують обмеження самостійно, принаймні ви знаєте, які таблиці потрібні один одному. Виконання обмежень всередині сервера полягає лише в тому, щоб двічі змінити (примусити)?

Зазвичай це не питання для вирішення, але ця база даних розроблена зовсім по-іншому. Дизайн виглядає регулярно добре, в основному це дзеркальні предмети, які використовуються додатками. Мене турбують всі обмеження, налаштовані всередині SQLserver з "не каскадом". Що означає, що вам потрібно грати "шукати і знаходити" при кодуванні нових запитів до бази даних. Деякі випадки вимагають до 10 рівнів точного порядку, щоб зробити одне видалення.

Це мене дивує, і я не впевнений, як з цим впоратися.

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

Як би ви діяли в цьому сценарії?
Чому б просто не видалити всі обмеження з db і тримати їх на рівні програми?

Дві загальні причини не видаляти протипоказання з БД :

• Зараз або в майбутньому доступ до нього може отримати більше додатків , які можуть або не можуть використовувати ORM. Навіть якщо розробники цих додатків сумлінно копіюють усі обмеження, які існують там (що може бути значно складніше, якщо використовувати рішення, що не мають ORM нижчого рівня), це завжди зайва робота. А якщо ні, навіть одного невеликого упущення достатньо, щоб порушити цілісність схеми ... це те, що ви не хочете ризикувати. У більшості компаній дані, що зберігаються в їх БД, є життєвою ланкою їхнього бізнесу, тому її цілісність повинна забезпечуватися будь-якими способами. І перевірений і перевірений найкращий спосіб досягти цього - це втілити якомога більше обмежень у БД.
• Оптимізатор запитів багато в чому покладається на обмеження, відомі на рівні БД. Якщо ви усунете обмеження, продуктивність запитів може почати погіршуватися . Ви можете не одразу помітити це, але одного дня він вдарить вас, і до того часу це може бути занадто пізно, щоб легко це виправити. Природа полягає в тому, що продуктивність БД має тенденцію до збою в час пікового навантаження, коли є найменша можливість зробити ретельне, продумане вдосконалення дизайну, підкріплене точними вимірюваннями продуктивності та детальним аналізом, щоб визначити першопричини.

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

Програми можуть надходити та йти, але дані живуть назавжди. У моїй компанії БД більше 30-40 років, вона буде жити, поки існує компанія. Програми змінюються, розробники приходять та йдуть. Краще мати цілісність і гарну логічну модель даних. Таким чином, хтось може переглядати дані та отримувати змістовне розуміння, не проходячи складну базу коду. Це також допомагає значно звітувати. Також програми можуть і матимуть помилки, а обмеження БД є захистом від цього. Моя позиція за замовчуванням - мати якомога більше обмежень (FK та чек).
Єдиною причиною не мати обмежень буде те, якщо модель дизайну цього не дозволяє, наприклад, проблеми « Таблиця за ієрархією» або продуктивністю.

Мене турбують всі обмеження, налаштовані всередині SQLserver з "не каскадом".

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

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

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

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

Я твердо переконаний, що це єдина сфера розробки програмного забезпечення, де ви не повинні застосовувати DRY (і я повністю сподіваюсь на те, що за цим твердженням є суттєвий аналіз). Ваші дані є серцем і душею вашої програми - якщо вона коли-небудь пошкоджена після ремонту, то це: гра закінчена. Варто ІМО виконувати обмеження, де вони потрібні. Якщо це означає у вигляді тригерів та обмежень на рівні БД, перевірки на сервері проміжного програмного забезпечення та JavaScript на стороні клієнта в інтерфейсі користувача (для веб-додатків), то IMO є необхідним злом для того, щоб дані завжди були незайманими .

Чи знаєте ви, що означає ORM? Об'єктно-реляційне відображення. Цитуючи Вікіпедію "техніка перетворення даних між несумісними системами типу". Так, реляційні та об'єктні моделі не підходять разом. ORM роблять досить хорошу конверсію, дотримуючись правил обох типів систем. RDBMS організовані таким чином, що ви досягаєте цілісності даних, використовуючи обмеження. Загалом, цілісність є дуже приємною річчю, тому ORM, як правило, використовує їх при створенні моделі даних для зберігання об'єктних даних. Ваш ORM, ймовірно, має вагомі підстави використовувати обмеження "не каскадні". І якщо це змушує вас робити складні запити замість того, щоб просто створювати / оновлювати / видаляти певні об'єкти, то з вашою установкою ORM щось не так.

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

Це саме те, що зробив eBay, і вони, мабуть, мають одну з найбільших баз даних у світі:

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

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

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

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

По-перше, моя відповідь: Ні, ви не повинні покладатися на програму лише для догляду за вашими даними.

Це вказує на більш широку дискусію: ORM заохочують культуру зневаги до "прямої" взаємодії з БД, часто за рахунок нормалізації / референтної цілісності. Таблиці насильно відображаються у довільній ієрархії об'єктів за рахунок конструкції, що міститься в реляційній моделі. Розв’язання, яке надає перевагу OOP, тут, безсумнівно, жертвується, оскільки додаток дає відчути дизайн у структурі даних. Незважаючи на те, що ORM продемонстрував велику корисність, вона, мабуть, базується на зловживанні або недовірі до SQL.

Нові парадигми (повторно) з'являються, наприклад, функціональне програмування. Якщо команда розробників вирішить застосувати нову методологію програмування, то які наслідки це матиме для даних, структурованих відповідно до вимог ORM?

Я погоджуюся з @Jacek Prucia - я думаю, що ORM - це погана відповідність для RDBMS, я особисто вибираю DBAL на RDBMS або йду на OODB з ORM.

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

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

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

(Що стосується питання каскаду: це добре. Я вважаю за краще помилитися з тим, що деякі інші записи спочатку потрібно видалити, а не покладатися на каскад, щоб все вийшло правильно. Каскади теоретично приємні, але не обов'язково так на практиці.)

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

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

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

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

Один з випадків, коли це працює, - це такі масивні корпоративні програми, як PeopleSoft і SAP, де програма вже робить практично все, і є ретельно визначені способи її розширення. Є й інші, дуже рідкісні, можливості.

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