Понимание денормализации

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

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

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

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

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

Она должна быть в первой нормальной форме, потому что имеет первичный ключ и нет повторяющихся групп. Она должна быть во второй нормальной форме, потому что есть только один ключ, поэтому не может быть частичных зависимостей. А третьей нормальной форме? Есть ли транзитивные зависимости? Похоже, что есть. Почтовый индекс, вероятно, определяется атрибутом Город. Чтобы преобразовать ее в третью нормальную форму, необходимо вынести Почтовый индекс в отдельную таблицу с Городом в качестве ключа. Однако в большинстве случаев это не стоит делать. Таким образом, хотя эта таблица не находится в третьей нормальной форме, разделение таблиц не стоит усилий. Чем больше таблиц, тем больше соединений нужно выполнять, что замедляет систему. Причина нормализации заключается в уменьшении размера таблиц за счет удаления избыточных данных, что часто может ускорить систему.

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