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

«Нормализация» применяется только и исключительно к логическому проекту базы данных.

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

Можно сказать, что логический проект нормализован или нет, но логический дизайн по своей сути не несет каких-либо «характеристик производительности» вообще. Так же, как 'c: = c + 1;' не несет никаких эксплуатационных характеристик.

На ваш вопрос есть очень простой ответ: это зависит.

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

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

Чтобы подчеркнуть некоторые моменты, сделанные в предыдущих плакатах: действительно ли ваша текущая схема денормализована? Правильный способ (imho) спроектировать базу данных:

• Как можно лучше понять систему / информацию для моделирования
• Построить полностью нормализованную модель
• Затем, если и как вы сочтете необходимым, денормализовать контролируемым способом, чтобы повысить производительность

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

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

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

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

Чтение меньшего количества более коротких строк означает меньшее количество физических операций ввода-вывода.

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

select count(*) from Post where BlogID = @BlogID

, что дороже, чем

select PostCount from Blog where ID = @BlogID

и может привести к SELECT N + 1 проблема, если вы не будете осторожны.

Конечно, со вторым вариантом вам придется иметь дело с сохранением целостности данных, но если первый вариант достаточно болезненный, тогда вы заставляете его работать.

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

Нормализованные схемы обычно лучше работают для INSERT / UPDATE / DELETE, потому что нет «аномалий обновления», а фактические изменения, которые необходимо внести, более локализованы.

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

Я хотел уточнить пункт 3 Хенрика Опеля . Затраты на разработку могут возрасти, но это не обязательно. Фактически, нормализация базы данных должна упростить или позволить использовать такие инструменты, как ORM, генераторы кода, средства записи отчетов и т. Д. Эти инструменты могут значительно сократить время, затрачиваемое на уровень доступа к данным ваших приложений, и перейти от разработки к добавлению бизнеса. значение.

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