Правило нормализует, пока не повредит, а затем денормализует, пока не сработает. (кто это сказал?)
В общем, я часто денормализуюсь, когда у меня много родительских и дочерних отношений, и я знаю, что мне часто приходится объединяться в пять или шесть больших таблиц, чтобы получить один фрагмент данных (например, идентификатор клиента), и не буду Нужна любая информация из промежуточных таблиц большую часть времени. Если это вообще возможно, я стараюсь денормализовать вещи, которые не будут часто меняться (например, поля id). Но всякий раз, когда вы денормализуете, вы должны написать триггеры или какой-то другой процесс (но обычно триггеры, если это не то, что может быть обработано через отношения PK / FK и каскадные обновления), чтобы убедиться, что данные синхронизированы. Если вам не удастся сделать это на уровне базы данных, у вас будут проблемы с целостностью данных, и ваши данные станут бесполезными. Не думайте, что вы можете поддерживать денормализацию через код приложения. Это рецепт для катастрофы, так как базы данных часто обновляются не из приложения, а из других мест.
Правильная денормализация может замедлить вставку, обновление и удаление, особенно если вам нужно делать большие пакеты данных. Это может или не может улучшить скорость выбора запроса в зависимости от того, как вам нужно запросить данные. Если вам в конечном итоге понадобится много самостоятельных соединений для получения данных, возможно, вам лучше не денормализовать. Никогда не денормализовать без тестирования, чтобы увидеть, если вы улучшили производительность. Помните, что замедление вставки / обновления / удаления будет иметь общее влияние на систему, когда многие пользователи используют его. Денормализация для устранения одной проблемы может привести к появлению худшей проблемы во всей системе. Не просто протестируйте один запрос, который вы пытаетесь ускорить, проверьте производительность всей системы. Вы можете ускорить выполнение запроса, который выполняется один раз в месяц, и замедлить выполнение других запросов, которые выполняются тысячи раз в день.
Денормализация часто выполняется для хранилищ данных, которые представляют собой особый случай, поскольку они обычно обновляются автоматически по расписанию, а не по одной записи за раз пользователем. Администраторы баз данных, специализирующиеся на хранилищах данных, также стремятся их создавать и знают, как избежать проблем с целостностью данных.
Другим распространенным методом денормализации является создание промежуточной таблицы для данных, относящихся к сложному отчету, который не нужно запускать с данными в реальном времени. Это своего рода хранилище данных бедного человека, и его никогда не следует делать без способа обновления промежуточной таблицы по расписанию (как это не часто случается, для этого используются серверные ресурсы, которые большую часть времени лучше было бы потратить в других местах). ) Часто эти типы таблиц обновляются, когда в системе мало пользователей и они отстают на целый день от данных в реальном времени. Не рассматривайте это, если только запрос, для которого вы размещаете данные, не является действительно медленным и не может быть иначе оптимизирован. Многие медленные запросы могут быть оптимизированы без деномализации, поскольку разработчики часто используют самые простые для понимания, а не самые эффективные способы выбора данных.