Сверхнормализация

Это всегда - вопрос домена приложения. Это обычно - вопрос правильности, но иногда вопрос производительности.

существует один случай, где я могу думать о наличии достаточно серьезных доказательств для возбуждения дела о сверхнормализации: скажите, что у Вас есть порядок + orderitem, и orderitem ссылки productID и листовая оценка к product.price. Так как это представляет временную связь, Вы неправильно нормализовали, потому что сверхнормализация уже влияет на доставленные заказы, если цены абсолютно никогда не изменяются. Можно, конечно, утверждать, что это - просто ошибка моделирования (как в комментариях), но я вижу под нормализацией как ошибка моделирования в большинстве случаев, также.

другая категория является связанной производительностью. В принципе я думаю, что существуют обычно лучшие решения производительности, чем денормализовывание данных, такие как осуществленные представления, но если Ваше приложение страдает от последствий производительности многих соединений, это может стоить оценить, может ли денормализовывание помочь Вам. Я думаю, что эти случаи часто слишком подчеркиваются, потому что люди иногда достигают денормализации, прежде чем они правильно представят свое приложение.

Люди также часто забывают об альтернативах, как хранение канонической формы базы данных и использования складирования или других стратегий часто считанных, но нечасто изменяемых данных.

Нормализация является абсолютной. База данных следует за Нормальными формами, или она не делает. Существует полдюжина нормальных форм. Главным образом у них есть имена как Сначала через Пятый. Плюс существует Нормальная форма Boyce-Codd.

Нормализация существует точно для одной цели - для предотвращения "аномалий обновления".

Нормализация не субъективна. Это не решение. Каждая таблица и отношения среди таблиц или делают или не следуют за нормальной формой.

, Следовательно, Вы не можете быть "сверхнормализованы" или "под - нормализованный".

Однако нормализации стоили производительности. Некоторые люди выбирают денормализовывать различными способами улучшить производительность. Наиболее распространенная разумная денормализация должна повредить 3 нФ и включать производные данные.

частая ошибка А состоит в том, чтобы повредить 2 нФ и иметь дубликаты функциональной зависимости между ключевым и незначением ключа. Это требует, чтобы дополнительные обновления или - хуже - триггеры сохранили копии параллельно.

Денормализация транзакционной базы данных должна быть индивидуальной ситуацией.

хранилище данных А, также, редко следует за любым из транзакционных правил нормализации, потому что оно (по существу) никогда не обновляется.

"Сверхнормализация" могла означать, что база данных является слишком медленной из-за большого количества соединений. Это может также означать, что база данных переросла аппаратные средства. Или что приложения не были разработаны для масштабирования.

наиболее распространенная проблема здесь - то, что люди пытаются использовать транзакционную базу данных для создания отчетов, в то время как транзакции продолжаются. Блокировка для транзакций вмешивается в создание отчетов.

"Под нормализацией", однако, средство, что существуют нарушения NF и бесполезная обработка, делается для обработки тиражируемых данных и корректных аномалий обновления.

Когда стоимость производительности превышает преимущество к намеченной цели приложения.

Много людей говорит о производительности. Я думаю, что ключевым вопросом является гибкость. В целом, чем более нормализованный Ваша база данных, тем более гибко это.

Мы в настоящее время используем "сверхнормализованную" базу данных, потому что в нашей операционной среде клиентские требования изменяются ежемесячно. Путем "сверхнормализации" мы можем принять наше программное обеспечение соответственно, не изменяя структуру базы данных.

.. или поражая пределы на количество соединений Ваш RDBMS сделает.

Мое взятие на этом:

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

Тогда реальное задание запускается: денормализация. Здесь Вы решаете то, что Вы знаете, было бы проблематично для реализации и/или замедлит запросы из-за слишком многих соединений.

Этот способ, которым Вы знаете то, для чего Вы рыхлите, делают дизайн применимым.

Редактирование: Документация! Я забыл упоминать, что документирование денормализации очень важно. Чрезвычайно полезно, когда Вы принимаете проект знать причину позади выбора.

Если производительность затронута слишком многими соединениями, составив денормализованные таблицы для создания отчетов, что цели могут ускорить вещи. Путем копирования данных в новые таблицы может быть возможно выполнить отчеты без соединений вообще.

По моему опыту, я никогда не видел нормализованную базу данных, которая содержит почтовые адреса, поскольку обычно приемлемо сохранить адрес как строку. Идеально, были бы таблицы для стран, округов / состояния, города, районы и улицы. Я не столкнулся ни с кем, кто должен сообщить на уличном уровне, таким образом, это не было необходимо. Адреса имеют только использоваться для почтового контакта, так рассматриваются как единственный объект.

В общем смысле я думаю, что сверхнормализовал, когда Вы делаете столько СОЕДИНЕНИЙ для получения данных, что это вызывает известные потери производительности и мертвые блокировки на базе данных, даже после настройки heck из индексов. Очевидно, для огромных приложений и сайтов как MySpace или eBay, денормализация является масштабирующимся требованием.

Как разработчик для нескольких предприятий малого бизнеса, я говорю Вам, что, по моему опыту, всегда было легче пойти от нормализованного-> денормализованный, чем наоборот, и на самом деле движение наоборот (для предотвращения дублирования данных теперь, когда бизнес-требования изменились, приблизительно один год позже) является намного более трудным.

, Когда я прочитал общие утверждения, такие как, "необходимо поместить адрес в потребительскую таблицу вместо отдельной таблицы адреса, таким образом, можно избежать соединения", я дрожу, потому что Вы просто знаете, что год с этого времени чья-то попытка попросить, чтобы Вы сделали что-то с адресами, которые Вы полностью не предвидели, как поддержание журнала аудита или хранение нескольких на клиента. Если Ваша база данных позволяет Вам создавать индексное представление, можно обойти ту проблему, пока Вы не переходите к сути дела, где Ваш набор данных является столь большим, что это не может возможно существовать или подается единственным сервером или набором серверов в 1 записи, среде много-чтения. Для большинства из нас я не думаю, что сценарий происходит очень часто.

, Когда в сомнении, я стремлюсь к третьей нормальной форме за некоторыми исключениями (например, имея поле содержат список CSV разделенных строк, потому что я знаю, что никогда не буду смотреть на данные из другого угла). Когда я должен буду консолидировать, я посмотрю на свои представления или индексирую сначала. Надежда это помогает.