Действительно ли лучше использовать нормализованные таблицы?

Question

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

Я думаю, что это может иметь какое-то отношение к объединениям таблиц.

Действительно ли более скудные столы менее эффективны, чем несколько толстых столов?

Answer 1

Это зависит ... объединение таблиц по своей природе медленнее, чем создание одной большой таблицы, которая «предварительно соединена», то есть не нормализована. Однако при денормализации вы создадите дублирование данных, и ваши таблицы будут больше. Нормализация рассматривается как хорошая вещь, потому что она создает базы данных, которые могут ответить на «любой» вопрос. Если это сделано правильно, вы можете создать выборку, чтобы получить доступ к вашим данным. Это не относится к некоторым другим формам БД, и в настоящее время это (в основном) исторические нерелевантности, БД с нормализованными отношениями выиграл эту битву.

Вернемся к вашему вопросу: использование нормализации для ускорения процесса является хорошо принятой техникой. Как правило, лучше всего запустить вашу БД на некоторое время, чтобы вы знали, что нужно нормализовать и что оставить в покое, а также часто оставляют данные в «правильной» нормализованной форме и извлекают данные в набор ненормализованных отчетов таблицы на регулярной основе. Если этот процесс выполняется как часть самого отчета, данные также всегда обновляются.

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

Answer 2

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

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

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

Нормализация базы данных и Денормализация лежат в основе этого компромисса.

Answer 3

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

Answer 4

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

OLAP - совсем другое животное, и я не могу комментировать это.

Answer 5

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

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

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

Answer 6

Производительность обратно пропорциональна количеству нормализации, выполненной в СУБД. При этом, чем более нормальны таблицы, тем меньше вероятность ошибок. Существует точка, в которой производительность СУРБД может быть снижена из-за денормализации, когда все данные хранятся в одной таблице.

Answer 7

Причина, по которой нормализация снижает производительность, заключается в том, что объединения довольно дороги. Если в таблице X имеется N записей, а в таблице Y - M записей, то объединение X и Y создает временную таблицу с количеством записей N * M. Хотя существуют приемы оптимизации, которые использует база данных, чтобы не генерировать всю таблицу, если она не нужна, тем не менее, она должна обрабатывать все записи.

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