Когда хорошее время должно повредить правила нормализации?
Дайте свое мнение о ситуациях, в которых это - хорошая идея НЕ нормализовать. Я просто засвидетельствовал некоторые горячие обсуждения между architech и DBA, кто настоял, в котором утверждал, что база данных была СЛИШКОМ нормализована.
10 ответов
Правило нормализуется, пока не болит, то денормализовать до того, что он работает. (Кто это сказал?)
В целом я часто денормализую, когда у меня есть много родительских дочерних отношений, и я знаю, что мне часто нужно присоединиться к пяти или шести большим столам, чтобы получить один кусок данных (скажем, идентификатор клиента Например) и не понадобится никакой информации из промежуточных таблиц большую часть времени. Если вообще возможно, я пытаюсь денормалировать вещи, которые не будут изменяться часто (такие как идентификационные поля). Но в любое время вы денормализуете, вам нужно писать триггеры или какой-то другой процесс (но обычно триггеры, если это не то, что можно обрабатывать через отношения PK / FK и каскадных обновлений), чтобы убедиться, что данные остаются в синхронизации. Если вы не сделаете это на уровне базы данных, у вас будут проблемы с целостностью данных, и ваши данные становятся бесполезными. Не думайте, что вы можете поддерживать денормализацию через код приложения. Это рецепт стихийных бедствий, так как база данных часто обновляется из мест, отличных от приложения.
Денормализация правильно может замедлить вставки, обновления и удаления, особенно если вам нужно делать большие партии данных. Это может или не может улучшить выбору скорости запроса в зависимости от того, как вам нужно запросить данные. Если вы в конечном итоге, нуждаетесь в том, чтобы сделать много самоуровнений, чтобы получить данные, возможно, вы бы лучше не денормализуют. Никогда не денормализируйте без тестирования, чтобы увидеть, если вы улучшены производительность. Помните, что замедление вкладыша / обновления / удаления будут иметь общий эффект в системе, когда многие пользователи используют его. Денормализуясь, чтобы исправить одну проблему, вы можете внедрять худшую проблему в общей системе. Не просто проверьте один запрос, который вы пытаетесь ускорить, проверить производительность всей системы. Вы можете ускорить запрос, который проходит один раз в месяц и замедлять другие QRERIES, которые проходят тысячи раз в день.
Денормализация часто выполняется для складов данных, которые являются специальным случаем, как они, как правило, автоматически обновляются на графике, а не в одну запись одновременно пользователем. DBA, которые специализируются на складировании данных, также имеют тенденцию к ним, и они знают, как избежать проблем целостности данных.
Еще одна общая методика денормализации состоит в том, чтобы создать установку таблицы для данных, связанных с комплексным отчетом, который не должен работать с данными в реальном времени. Это своего рода хранилище данных плохого человека и никогда не должно быть сделано без способа обновить установленную таблицу по расписанию (так же нечасто, как вы можете уйти, это использует серверные ресурсы, которые могут лучше потратить в другое место в другом месте. ) Часто эти типы таблицы обновляются, когда в системе есть несколько пользователей и отстают полный день за данными в реальном времени. Не считайте это, если запрос вы не постановляете, данные для действительно медленные и не могут быть оптимизированы. Многие медленные запросы могут быть оптимизированы без деномализации, поскольку разработчики часто используют самые простые для понимания, а не самых исполнительных способов выбора данных.
Производительность возможностей запроса: если БД слишком нормализован, это может привести к большому количеству соединений в ваших запросах, и ограничивает ваши возможности поиска по конкретным атрибутам. При выполнении DB Design вы должны рассмотреть вопрос, который вы планируете использовать его, выполняя анализ пути доступа.
Чтобы разработать, это правило для нормализации данных, которые часто обновляются, и денормализовать данные, которые в основном прочитаны.
Когда вы оптимизируете преждевременно
Некоторые нормализации, чтобы позволить будущему росту, и вам, возможно, не понадобится.
Например, представьте, что у вас есть человек Таблица . Вы можете иметь день рождения как колонка, потому что у каждого человека когда-либо будет только один день рождения.
Если вы строго нормализуете, у вас не было бы Phone_number и Cell_Number и FAX_NUMBER как в человек , но Возможно вместо этого есть Phonenumber таблицу, где каждая строка имеет номер, тип, а также отношение к лицу. Это может быть лучше, чем просто прилипать новых столбцов в таблице , потому что
- Многие люди не будут иметь всех тех, оставив много пробелов, а
- , если у кого-то есть 3 ячейки Вы будете добавлять неловкие колонны, такие как
CELL_NUMBER_2
Концерн № 1 действительны, но беспокойство № 2 может быть примером «Вы не понадобятся». Действительно сказать, что «мы разрешаем только один номер ячейки, и это то, что». В этом случае вы можете не пройти отдельную таблицу телефонных номеров.
Это компромисс. Не делая отдельной таблицы, вы не строго нормализуете, и у вас может быть много нулевых пространств. Но у вас также есть меньше присоединений, и это просто меньше работы.
Как и многие передовые практики, нормализация может стать само по себе - золотой значок, который вы даете себе в частном порядке, потому что вы сделали это правильно. И это нормально. Но приятно осознавать, что правила могут быть согнуты иногда в интересах сохранения вещей простых.
Последнее: Вы должны взвесить тот факт, что он отстой, чтобы изменить схему БД, как только ваш код будет запущен и запущен. Так что это нормально, чтобы сказать: «Мы не понадобится, - но старайтесь быть уверены, прежде чем делать.
Несколько хороших ответов уже на рабочем состоянии VS, но, кроме того, добавляем настроить то, что следует учитывать еще одну индикацию для меня, что необходимо учитывать де-нормализацию, - это то, что вы должны потребовать запросов используя самоучатки.
Концептуально, конечно, нет ничего плохого в том, что с автоприсоединением нет, но опыт показывает, что это одна из более сложных концепций неопытных программистов, чтобы понять, и, следовательно, имеет тенденцию производить ошибки. Скорее всего, вы будете упростить будущее путь обслуживания, если вы можете разработать необходимость этого.
Это вопрос суда, конечно, и так является признаком, а не правилом.
Вы должны найти сладкое место ... быть слишком нормализованным, вы в конечном итоге с большим количеством «Bloaty» абстрактных конструкций, которые содержат всего 1 или 2 столбца данных, и вы в конечном итоге присоединяетесь к 5 таблицам для большинства запросов.
Не нормировано, вы в конечном итоге имеете много данных во многих разных местах. Это может привести к тому, что БД медленнее из-за размера кэша и такого. Кроме того, теперь, когда вам нужно что-то обновить, у вас есть 4 разных таблицы для обновления вместо 1, и даже не запускайте меня, чтобы убедиться, что все данные в разных местах совпадают!
В основном выберите свой яд и посмотрите, как будет использоваться ваша БД, и будьте в здравом уменьшении. Все правила должны были быть сломанными, и если у вас есть кусок данных, возможно, 2 места, которые очень часто обращаются, я бы сказал, что это нормально. Это критический элемент, где соединение (возможно, более 2) таблиц может быть просто слишком дорогим .. Но также не используйте микро-оптимизировать для пробела или скорости базы данных.
работал в месте, где они слишком много нормализуются. Они удалили «государственный» столбец из таблицы почтового адреса. В месте 2-байтового состояния столбца они поместили целовое поле внешнего ключа, связывающее на государственную таблицу.
Таким образом:
они заменили 2 байтовой колонне состояния с 4 байтовым столбцом в адресе. стол. Теперь каждая строка занимает 2 байта хранения.
Они добавили таблицу состояния с 4 байтом первичного ключа столбца и 2-байтовый государственный столбец. Занимает больше места для хранения этой таблицы.
База данных хранит индекс BTREE клавиш в состоянии состояния. Занимает больше места.
SQL для извлечения адресов сложнее писать.
SQL для извлечения адресов медленнее, чем оригинал.
Конечно, это наивно удаляет дублированные неизменные данные. В результате он использует больше дискового пространства, сложнее использовать и медленнее использовать.
Вы определенно можете нормализовать слишком много.
Нормализация устраняет избыточность, но если она замедляет производительность (благодаря всем необходимым присоединениям) затраты на оборудование неадекватны, пришло время, чтобы позволить избыточности для производительности. Это мое правило. Же в случае длительного ответа времен.
Отчетность и хранение данных, вероятно, являются самыми крупными местами, которые вы найдете данные денормализованные. Системы OLAP , как правило, всегда будут денормализовать в одну таблицу или набор таблиц.
Не нормализуются, когда вы следуете за дизайнерской дисциплиной, которая приводит к менее чем в полно нормализованной схеме. Одной из таких дизайнерской дисциплины является дизайн STAR SCHEMA, а близкий вариант этого - Схема снежинки.
Оба звезды и снежинки приведут к схеме, которая гораздо проще в использовании для различных отчетов, настроенных экстрактов и интерфейса к инструменту OLAP, такого как POWER POWER. Обратная сторона? Каждый отъезд из одной из обычных форм (кроме 1НФ) содержит аномалию при вставке / обновлении / удалении данных. Если вы действительно знаете нормальные формы, вы узнаете, что являются связанными аномалиями. Когда вы пишете процедуры ETL (Extract, Transform и Load), чтобы сохранить свой ток звезды / снежинки, вам придется работать вокруг этих аномалий.
Итак, когда это схема звезды или снежинки лучше, чем нормализованная схема? Как правило, для хранилищ данных, Data Marts и базы данных отчетности. В своей собственной практике я никогда не построил один из них, который не был задним концом для базы данных OLTP, а база данных OLPT пособия почти полной нормализации. Не просто денормализовать и отказаться от всей дисциплины. Это как дизайн наугад.
Хранилище данных часто использует ненормализованный подход из соображений производительности. Согласно википедии:
Стандартное руководство по проектированию баз данных заключается в том, что проектировщик должен создать полностью нормализованную конструкцию; выборочная денормализация в дальнейшем может быть выполнена из соображений производительности. Однако некоторые дисциплины моделирования, такие как подход к проектированию хранилищ данных с использованием размерного моделирования, однозначно рекомендуют ненормализованные конструкции, т.е. конструкции, которые в значительной степени не соответствуют 3NF.