Чи нормалізація бази даних мертва? [зачинено]

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

З появою деяких фреймворків ORM, таких як ActiveRecord Ruby або ActiveJDBC (і деяких інших, яких я не можу згадати, але я впевнений, що їх багато), схоже, вони вважають за краще мати сурогатний ключ для кожної таблиці, навіть якщо в деяких є первинні ключі, наприклад "електронна пошта" - виривання 2NF прямо. Гаразд, я не дуже розумію, але це стає мені на нерви (майже), коли деякі з цих ОРМ (або програмістів) не визнають 1-1 або 1-0 | 1 (тобто 1 до 0 або 1). Вони стверджують, що просто краще мати все як один великий стіл, незалежно від того, чи є він у тоні nulls "сьогоднішні системи можуть це впоратися" - це коментар, який я чув частіше.

Я погоджуюся, що обмеження пам'яті несло пряме співвідношення з нормалізацією (є й інші переваги :), але в сьогоднішній час з дешевою пам'яттю та чотирьохядерними машинами концепція нормалізації БД залишається лише текстами? Як DBA ви все ще практикуєте нормалізацію до 3NF (якщо не BCNF :)? Це важливо? Чи хороша конструкція "брудної схеми" для виробничих систем? Тільки, як слід зробити випадок «для» нормалізації, якщо він все ще актуальний.

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

Однією з причин нормалізації є усунення аномалій модифікації даних.
ОРМ зазвичай цього не підтримують.

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

• роздутий (рядок повторюється понад 100 мільйонів рядків)
• немає таблиць пошуку (див. вище)
• немає DRI (обмеження, клавіші)
• варчар кластерні індекси
• непотрібні таблиці посилань (наприклад, примусово застосовувати 1..0: 1, коли нульовий стовпець FK буде достатній)

Найгірше, що я бачив - це база даних MySQL 1 ТБ, яка, можливо, через 75-80% була занадто великою

Я також припускаю, що твердження "сьогоднішні системи можуть це впоратися" справедливо для більшості систем Міккі Мауса. У міру масштабування сьогоднішні системи не будуть.

У моєму прикладі вище, не було тяги до рефактора або зміни ключів чи виправлення даних: просто скаржитися на темпи зростання бази даних та неможливість побудови значущої DW поверх неї

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

Сурогатні ключі не розривають 2NF. 2NF говорить: "Якщо стовпець залежить лише від частини багатозначного ключа, видаліть його в окрему таблицю".

Вони зазначають, що просто краще мати все як один великий стіл, незалежно від того, чи є він тоном нулів

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

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

Нормалізація - це не тільки для збереження пам'яті чи диска, саме для додання цілісності. Адже це математичне поняття, незалежне від апаратних засобів.

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

Rec 1: Середня школа North Ridge, Каліфорнія, США

Rec 2: Середня школа Південного Торонто Браувса, Онтаріо, Канада

Якщо ви запитаєте свою систему, де знаходиться Онтаріо, ви можете дізнатися, що вона знаходиться в Канаді. Через кілька днів ви видалите 2-й ряд і задасте системі те саме питання, і нічого не отримаєте. У цьому прикладі, не маючи скільки дискового простору чи пам'яті чи процесора, відповіді ви не отримаєте.

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

Редагувати: Змінено слово Торонто на Онтаріо відповідно до коментаря нижче.

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

Це колись заважало COBOL-натхненним структурам даних у ранні RDBMS, або жахливий Богом хаос, який був dBase. Тепер це ORM та "Code-First". Зрештою, це все просто способи людей, які намагаються знайти срібну кулю роботи робочої системи, не витрачаючи часу на роздуми над тим, що ти хочеш і потрібно робити. Поспішати завжди було проблемою і завжди буде проблемою.

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

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

Я погоджуюся, що обмеження пам’яті несли пряму кореляцію з нормалізацією ...

Обмеження пам'яті все ще має значення. Кількість - це не проблема, швидкість - це.

• Наразі процесори не стають швидшими (ми отримуємо більше основних, а не циклів в секунду)
• Сучасні архітектури процесора намагаються подолати обмеження швидкості, забезпечуючи окрему пам'ять для кожного процесора ( NUMA ).
• Розміри кеш-пам’яті без збільшення не збільшуються порівняно з основною пам'яттю.
• Пропускна здатність пам'яті не така висока, як очікує більшість людей. QPI знаходиться в районі 25 Гб / сек.

Частина цього ґрунту була висвітлена у розділі Коли використовувати TINYINT над INT? що вам може бути корисним. Я б також запропонував дотримуватися витівки @ThomasKejser ( блогу ) від команди SQLCAT, оскільки вони, як правило, знаходяться на різкій межі, що підштовхує продуктивність бази даних. Нещодавній допис про Ефект кеш-процесорів та шаблонів доступу до пам'яті та презентація SQLBits про реляційне моделювання для масштабування Extreme DW є хорошими прикладами.

На мою думку, мова йде лише про баланс між нормалізацією та денормалізацією . Я повністю згоден , що рамки ОРЗ є тільки підходи , Getting Things Done, але я не думаю , що ці механізми , що викликають де-нормалізувати тенденцію.

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

Зараз речі бувають зовсім інші, зберігання дуже дешеве. Тож очевидно, що ми можемо терпіти більше надмірностей порівняно зі старими часами, це також ЧОМУ з'явився BIG_TABLE підхід. Для досягнення більшої ефективності в часі космічну ефективність потрібно принести в жертву.

Але підхід на великій таблиці також не є кінцем історії, це все-таки баланс між часом і простором, з точки зору даних про обсяг PB для управління, деякі розробники також почали шукати баланс назад до ефективності простору, саме тому - це роботи, спрямовані на нормалізацію деяких даних у структурах типу BIG-TABLE.

Одним словом, підхід до нормалізації не є однозначно мертвим, але в порівнянні зі старими даними він безумовно не помічений.

CJ Date відповідає тут на ваше запитання - нормалізаційне (попереднє) відео безкоштовно.

http://shop.oreilly.com/product/0636920025900.do

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