Ответы:
Вы должны идти так далеко, как вы должны, и не дальше. Конечно. ~ Проблема может быть в том, что это что-то вроде искусства, и именно поэтому это не чистая наука.
Нашим основным продуктом является система анализа и отчетности, поэтому в этом отношении у нас есть довольно много подробных записей. Первоначально он был разработан с множеством объединений с общим идентификатором для некоторых дочерних записей, но мы обнаружили, что, если мы денормализуем пару полей, мы сможем вырезать ОЧЕНЬ много объединений и мы сможем избавиться от многих проблем с производительностью.
Но мы знали только, что, поскольку мы 1) создали «нормализованный» дизайн, 2) начали использовать его, 3) оценили фактическую производительность после сотен миллионов строк в десятках таблиц.
Конечная история заключается в том, что до тех пор, пока мы не профилировали, мы не могли точно знать, что будет работать для нас. Нам понравилась идея нормализации, чтобы мы могли легче обновлять, но в конечном итоге реальная производительность была решающим фактором. Это мой совет для вас: профиль, профиль, профиль.
in ('forgiven','pardoned');): p
Нормализация является целью только тогда, когда она достаточно хорошо поддерживает вашу модель данных, чтобы оправдать ее. Он предназначен для того, чтобы служить руководством для обеспечения роста, управления и обслуживания. Помните, что книга по нормализации, ни ее автор не собираются создавать или поддерживать вашу базу данных или ее приложение.
Хорошее прочтение на тему «слишком много нормализации» здесь.
И да, это может повлиять на производительность слишком много нормализации. Это было бы более глубоким обходом таблицы, чтобы подобрать такие вещи, как таблицы индикаторов состояния, когда они были перенесены в отдельную таблицу. Кто-то скажет, что это обычно сводится на нет в скорости обновления (изменение текста состояния с «Хорошо» на «ХОРОШО» или что-то подобное) или в удобстве обслуживания.
Я рекомендую прочитать следующее приложение, которое можно найти в нескольких более поздних книгах Криса Дейта :
Два Приветствия Для Нормализации
Нормализация отнюдь не панацея, как мы можем легко увидеть, если подумать, каковы ее цели и насколько хорошо она противостоит им ...
Я должен дать понять, что не хочу, чтобы мои комментарии в этом разделе рассматривались как какая-либо атака. Я твердо верю, что что-либо меньшее, чем полностью нормализованный дизайн, категорически противопоказано ...
Я думаю, что не менее важно взглянуть на явную добавленную денормализацию: добавленные совокупные значения или некоторые поля из основной таблицы, скопированные в детальную копию.
Аргумент в основном является аргументом производительности.
Если вы сделаете это принудительно, эти поля будут обновлены триггерами, и база данных будет поддерживать их согласованность.
Я полностью согласен с @jcolebrand. Когда вы разрабатываете модель для своего приложения, вы должны нормализовать все, что можете. Но тогда вы должны профилировать запросы, построенные на вашей модели, особенно те, которые выполняются часто.
Мой собственный опыт: атрибуты, для достижения которых потребовалось два объединения (это означает, что три таблицы объединились) будут в основном повышать производительность. И что еще хуже, он используется в онлайн-транзакциях. Я денормализовал атрибут, так что ему просто нужно одно соединение и попросил программиста настроить приложение для запроса и обновить атрибут. Теперь это работает намного лучше ...
Другими словами, вы должны сбалансировать нормализацию с производительностью.