Що цікаво в цій темі запитань і запитань, це те, що насправді є 3 питання. Усі відповіли на інший, і майже ніхто не відповів на перший:
- Чому НЕ деякі бази даних в дикій природі нормалізувалися?
- Чому / коли слід денормалізувати нормалізовану базу даних ?
- У яких ситуаціях шкідливо чи непотрібно в першу чергу нормалізуватися?
Читачі сповіщень зазначать, що це дуже різні запитання, і я спробую відповісти на кожне з них окремо, уникаючи занадто багато деталей. "Занадто багато" я маю на увазі, що я не думаю, що це відповідний контекст, в якому слід проводити розширену дискусію щодо суті різних аргументів на користь або проти нормалізації; Я просто поясню, що це за аргументи, можливо, перелічу декілька застережень і збережу філософію для більш конкретних питань, якщо вони коли-небудь з’являться.
Крім того, у цій відповіді я припускаю, що "нормалізація" передбачає "BCNF, 3NF або, принаймні, 2NF" , оскільки саме такий рівень нормалізації прагнення досягти дизайнерам. Рідше бачити конструкції 4NF або 5NF; хоча вони, безумовно, не є неможливими цілями, вони стосуються семантики відносин, а не просто їх представлення , що вимагає значно більше знань про область.
Отже, вперед і вгору:
1. Чому деякі бази даних у дикій природі не нормалізуються?
Відповідь на це могла б бути "тому, що їх не повинно бути", але зробити це припущення відразу ж у кар'єра - досить бідна детективна робота. Ми не мали би великого прогресу як суспільство, якби завжди працювали з припущенням, що все, що повинно бути, повинно бути.
Справжні причини того, що в першу чергу бази даних не нормалізуються, є складнішими. Ось топ 5, на які я потрапив:
Розробники, які розробили це , не знали або не розуміли, як це нормалізувати. Справжні докази цього є у вигляді багатьох інших супутніх поганих варіантів дизайну, як, наприклад, використання колонок varchar для всього або наявність спагетті безглуздих назв таблиць і стовпців . І я запевняю вас, я бачив "справжні" бази даних, які є настільки ж поганими, як і статті у TDWTF.
Розробники, які розробили це , не хвилювались чи були активно проти принципу нормалізації . Зауважте, тут я не говорю про випадки, коли було прийнято обдумане рішення не нормалізуватись на основі контекстуального аналізу, а про команди або компанії, де нормалізація більш-менш зрозуміла, а просто ігнорується або уникається від звички. Знову ж таки, напрочуд поширене.
Програмне забезпечення / було зроблено як проект Brownfield . Багато пуристів ігнорують цей ідеально законний бізнес, а не технічний причину не нормалізації. Іноді ви насправді не спрацьовуєте створити нову базу даних з нуля, вам доводиться переходити до існуючої застарілої схеми, а спроба її нормалізації в цей момент спричинить набагато біль. 3NF не був винайдений до 1971 року, і деякі системи - особливо фінансові / бухгалтерські - мають коріння ще далі, ніж це!
База даних була спочатку нормалізована , але накопичення невеликих змін протягом тривалого періоду часу та / або широко розповсюджена команда впроваджувала тонкі форми дублювання та інші порушення будь-якої нормальної форми. Іншими словами, втрата нормалізації була випадковою , і занадто мало часу було витрачено на рефакторинг.
Було прийнято обдумане бізнес-рішення не витрачати часу на аналіз бізнесу чи розробку баз даних, а просто "виконати це". Це часто є помилковою економією і в кінцевому підсумку стає все більшою формою технічної заборгованості , але іноді є раціональним рішенням, принаймні на основі відомостей, відомих у той час - наприклад, база даних, можливо, була задумана як прототип, але закінчилася сприяння виробничому використанню через часові обмеження або зміни в бізнес-середовищі.
2. Чому / коли слід денормалізувати нормалізовану базу даних?
Це обговорення часто з'являється , коли база даних буде нормалізована , щоб почати с. Або продуктивність погана, або є багато дублювання запитів (приєднується), і команда відчуває, правильно чи неправильно, що вони зайшли в міру поточного дизайну. Важливо зауважити, що нормалізація покращує продуктивність більшу частину часу, і є кілька варіантів усунення зайвих приєднань, коли нормалізація, здається, працює проти вас, багато з яких менш інвазивні та ризиковані, ніж просто перехід на денормалізовану модель:
Створіть індексовані подання, які інкапсулюють найпоширеніші проблемні області. Сучасні СУБД можуть зробити їх вставними або оновленими (наприклад, INSTEAD OFтригери SQL Server ). Це виходить з невеликими витратами на висловлювання DML в базових таблицях / індексах, але, як правило, це перший варіант, який слід спробувати, тому що майже неможливо викрутити і майже нічого не коштує підтримувати. Звичайно, не кожен запит може бути перетворений на індексований вигляд - сукупні запити є найскладнішими. Що призводить нас до наступного пункту ...
Створіть денормалізовані сукупні таблиці, які автоматично оновлюються тригерами. Ці таблиці існують на додаток до нормалізованих таблиць і утворюють своєрідну модель CQRS . Іншою моделлю CQRS, більш популярною в наші дні, є використання pub / sub для оновлення моделей запитів, що дає перевагу асинхронії, хоча це може бути непридатним у дуже рідкісних випадках, коли дані не можуть бути несвіжими.
Іноді індексовані представлення неможливі, швидкість транзакцій та обсяги даних занадто високі, щоб допускати тригери з прийнятною ефективністю, і запити завжди повинні повертати дані в реальному часі. Такі ситуації трапляються рідко - я б загрожував припущенням, що вони можуть застосовуватись до таких речей, як високочастотна торгівля або бази даних правоохоронних / розвідувальних даних, - але вони можуть існувати. У цих випадках у вас дійсно немає іншого можливості, крім денормалізації оригінальних таблиць.
3. У яких ситуаціях шкідливе чи непотрібне в першу чергу нормалізуватися?
Насправді є кілька хороших прикладів тут:
Якщо база даних використовується лише для звітування / аналізу. Зазвичай це означає, що для OLTP використовується додаткова нормалізована база даних, яка періодично синхронізується з базою даних аналізу через ETL або обмін повідомленнями.
При застосуванні нормованої моделі потрібен буде зайвий складний аналіз вхідних даних. Прикладом цього може бути система, якій потрібно зберігати телефонні номери, зібрані з декількох зовнішніх систем або бази даних. Ви можете денормалізувати код виклику та код області, але вам доведеться враховувати всі можливі формати, недійсні номери телефонів, суєтні номери (1-800-GET-STUFF), не кажучи вже про різні локалі. Зазвичай це більше клопоту, ніж коштує, і телефонні номери зазвичай просто заносять в одне поле, якщо у вас немає конкретної потреби бізнесу в коді району самостійно.
Коли реляційна база даних передусім є для забезпечення транзакційної підтримки для додаткової, нереляційної бази даних. Наприклад, ви можете використовувати реляційну базу даних в якості черги повідомлень або відстежувати стан транзакції або саги, коли основні дані зберігаються в Redis або MongoDB або будь-якому іншому. Іншими словами, дані - це "контрольні дані". Зазвичай немає сенсу нормалізувати дані, які насправді не є бізнес-даними .
Сервісно-орієнтовані архітектури, які мають спільну фізичну базу даних. Це трохи дивним один, але в істинному SOA, ви будете час від часу необхідно мати дані фізично дублюється , оскільки послуги не можуть безпосередньо запитувати дані один одного. Якщо вони трапляються , щоб ділити ту ж фізичну базу даних, дані будуть відображатися НЕ будуть нормалізовані - але , як правило, дані , що належать кожній окремій послуги є ще нормалізовані , якщо один з інших пом'якшуючих факторів не на місці. Наприклад, послуга виставлення рахунків може бути власником суб'єкта векселя, але служба бухгалтерії повинна отримувати та зберігати дату та суму рахунків, щоб включити їх у дохід за цей рік.
Я впевнений, що є більше причин, які я не перераховував; Що я розумію, по суті, це те, що вони є досить конкретними і будуть досить очевидними, коли вони з'являться на практиці. Бази даних OLAP повинні використовувати зіркові схеми, SOA повинні мати деяке дублювання тощо. Якщо ви працюєте з відомою архітектурною моделлю, яка просто не працює з нормалізацією, то ви не нормалізуєтесь; загалом кажучи, модель архітектури має перевагу над моделлю даних.
І щоб відповісти на останнє запитання:
Чи правда, що хороші архітектори та експерти вибирають денормалізований дизайн, тоді як не досвідчені розробники вибирають навпаки? Які аргументи проти того, щоб розпочати дизайн з урахуванням нормалізації?
Ні, це повно і повністю BS Це також BS, що фахівці завжди вибирають нормалізовану конструкцію. Експерти не просто слідують за мантрою.Вони досліджують, аналізують, обговорюють, уточнюють та повторюють, а потім обирають будь-який підхід, який має найбільше значення для їх конкретної ситуації.
База даних 3NF або BCNF, як правило, є гарною відправною точкою для аналізу, оскільки вона була випробувана і зарекомендувала себе успішною в десятках тисяч проектів по всьому світу, але знову ж таки, так це і C. Це не означає, що ми автоматично використовуємо C у кожному новий проект. Ситуації в реальному світі можуть вимагати деяких модифікацій моделі або взагалі використання іншої моделі. Ви не знаєте, поки не опинитесь у цій ситуації.