Відповіді:
Вам слід йти, як слід, і не далі. Звичайно. ~ Проблема може полягати в тому, що це трохи мистецтво, і тому це не є чистою наукою.
Наш головний продукт - це система аналізу та звітності, і тому в цьому плані ми маємо досить багато детальних записів. Спочатку ми розробили це з великою кількістю приєднань до загального посвідчення для деяких дитячих записів, але ми виявили, що якби ми денормалізували пару полів, ми могли б вирізати багато приєднань і ми могли б забрати багато головних болів у роботі.
Але ми лише знали, що тому, що ми 1) створили «нормалізований» дизайн, 2) почали його використовувати, 3) профілювали фактичну ефективність після сотень мільйонів рядків у десятках таблиць.
Кінцева історія полягає в тому, що, поки ми не профілювались, ми не могли точно знати, що буде працювати для нас. Нам сподобалася ідея нормалізації, щоб ми могли простіше оновити, але врешті-решт, вирішальним фактором стала фактична ефективність. Це моя порада для вас: профіль, профіль, профіль.
in ('forgiven','pardoned');): p
Нормалізація є ціллю лише тоді, коли вона підтримує вашу модель даних досить добре, щоб гарантувати її. Він повинен бути керівництвом для забезпечення зростання, управління та ремонту. Пам'ятайте, що книга про нормалізацію, а також її автор не збираються будувати або підтримувати вашу базу даних або її застосування.
Добре читати на тему "занадто багато нормалізації" тут.
І, так, можливі наслідки надмірної нормалізації роботи. Це було б у більш глибокому обході таблиці, щоб забрати такі речі, як таблиці індикаторів стану, коли їх витягнули до окремої таблиці. Деякі кажуть, що це зазвичай заперечується в швидкості оновлення (зміна тексту статусу з "Добре" на "ДОБРО" або щось подібне) або в ремонтопридатності.
Рекомендую прочитати наступний додаток, знайдений у кількох останніх книгах Кріса Дата :
Нормалізація - це далеко не панацея, як ми легко бачимо, розглядаючи, які її цілі і наскільки вдало вони проти них ...
Я маю дати зрозуміти, що я не хочу, щоб мої коментарі в цьому розділі розглядалися як будь-яка атака. Я твердо вірю, що нічого, крім повністю нормалізованого дизайну, категорично протипоказано ...
Я думаю, що не менш важливо переглянути чітко додані денормалізації, або додані сукупні значення, або деякі поля з головної таблиці, скопійованої в копію деталей.
Аргумент здебільшого є деяким аргументом ефективності.
Якщо ви це зробите, ці поля оновлюються тригерами, і це залежить від бази даних, щоб підтримувати їх послідовність.
Я повністю згоден з @jcolebrand. Розробляючи модель для своєї програми, ви повинні нормалізувати все, що можете. Але тоді вам слід надати запити, побудовані над вашою моделлю, особливо ті, які часто виконуються.
Мій власний досвід: атрибути, до яких потрібно було приєднатись два об'єднання (це означає, що три таблиці приєднані), будуть здебільшого виступів. А для того, щоб зробити найгірше, він використовується в рамках операцій по лінії. Я денормалізую атрибут, тому йому потрібно лише одне приєднання і попросив програміста відрегулювати їх додаток для запиту та оновлення атрибута. Зараз це працює набагато краще ...
Іншими словами, ви повинні збалансувати нормалізацію та продуктивність.