Как вы определяете, насколько далеко можно нормализовать базу данных?

Ответ 1

Вы хотите начать разработку нормализованной базы данных до третьей нормальной формы. По мере развития уровня бизнес-логики вы можете решить, что вам придется денормализовать бит, но никогда, никогда не опускайтесь ниже третьей формы. Всегда соблюдайте 1-й и 2-й формы. Вы хотите денормализовать для простоты кода, а не для производительности. Используйте индексы и хранимые процедуры для этого:)

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

Есть несколько хороших статей:

http://www.agiledata.org/essays/dataNormalization.html

Ответ 2

@GrizzlyGuru Мудрый человек однажды сказал мне "нормализовать, пока это не повредит, денормализовать, пока он не сработает".

Это еще не подвело меня:)

Я не согласен с тем, чтобы начать с него в ненормализованной форме, однако, по моему опыту, "было легче адаптировать ваше приложение для работы с менее нормализованной базой данных, чем с более нормализованной. Это может также привести к ситуациям, когда его" работа "достаточно хорошо", поэтому вы никогда не сможете его нормализовать (пока его "слишком поздно!"

Ответ 3

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

Это довольно большая проблема, поэтому я бы сказал, что денормализация болит, а не наоборот.

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

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

Ответ 4

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

Ответ 5

Нормализация базы данных Я чувствую, что это художественная форма.

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

Хорошее эмпирическое правило, которое я придерживаюсь, - это нормализовать ту же информацию, которая повторяется снова и снова.

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

Однако, если у вас есть только два типа контактов, бизнес или личный, вам нужна таблица типа контакта, если вы знаете, что у вас будет только 2? Для меня нет.

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

Пусть тестирование скажет вам, нужно ли комбинировать таблицы. Хорошо написанный запрос может охватывать любую нормализацию.

Ответ 6

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

Ответ 7

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

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

Ответ 8

Оригинальный плакат никогда не описывался в какой ситуации база данных будет использоваться. Если это будет какой-либо проект хранилища данных, где в какой-то момент вам понадобятся данные обработки кубов (OLAP) для некоторых интерфейсов, было бы разумнее начать с звездной схемы (таблицы фактов + измерение), а не смотреть в нормализация. В этом случае книги Кимбалла будут очень полезны.

Ответ 9

Я согласен, что обычно лучше начинать с нормализованной БД, а затем денормализовать, чтобы решить очень специфические проблемы, но я, вероятно, начинал бы с Boyce -Codd Normal Form вместо третьей нормальной формы.

Ответ 10

Истина заключается в том, что "это зависит". Это зависит от множества факторов, включая:

• Код (ручной или управляемый инструментом (например, пакеты ETL))
• Первичное приложение (обработка транзакций, хранение данных, отчетность)
• Тип базы данных (MySQL, DB/2, Oracle, Netezza и т.д.)
• Архитектура базы данных (Tablular, Columnar)
• Качество DBA (активный, реактивный, неактивный)
• Ожидаемое качество данных (вы хотите обеспечить качество данных на уровне приложения или уровне базы данных?)

Ответ 11

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

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

Если вы денормализуете, вам либо нужно жить с тем фактом, что вы можете получить аномалии обновления, либо вам нужно реализовать проверку соответствия самостоятельно в своем коде приложения. Это отнимает много пользы от использования СУБД, которая позволяет описать эти ограничения декларативно.

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

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

Ответ 12

Часто, если вы нормализуете свое свободное программное обеспечение, вы сделаете это.

Например, при использовании технологии объектно-реляционного сопоставления у вас будет богатый набор семантики для различных отношений "многие-к-одному" и "многие ко многим". Под капотом, который обеспечит объединение таблиц с эффективными двумя первичными ключами. Хотя относительно редко, нормальная нормализация часто дает вам отношения с 3 или более первичными ключами. В таких случаях я предпочитаю придерживаться O/R и сворачивать свой собственный код, чтобы избежать различных аномалий DB.

Ответ 13

Просто попробуйте использовать здравый смысл.

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

Ответ 14

Не забывайте Мать всех дебатов по нормализации базы данных в Coding Horror (обобщенно в блоге High Scalability).