Да и нет.
Это сознательно идет вразрез с принципом нормализации базы данных и поэтому называется "денормализация".
Его плохие моменты - в значительной степени все причины, по которым мы нормализуем, в особенности то, что он вводит способ, которым ошибка может сделать базу данных несовместимой с самой собой. В общем, поэтому, это плохой дизайн БД. На практике это также делает обновления базы данных более сложными и, следовательно, более дорогими (и это при условии отсутствия ошибок).
Тем не менее, он может дать преимущества производительности для некоторых запросов, которые отличаются разницей между тайм-аутом и тривиальностью. Поэтому это разумная, а иногда и существенная оптимизация.
Мне нравится следующий подход к этому:
* * 1010
Дважды подумайте о своей необходимости. В частности, в CTE есть некоторые случаи, в которых я бы больше не прибегал к этой методике, поскольку CTE может делать то, что раньше требовало нескольких просмотров таблиц всего за пару (в действительности, в большинстве случаев, когда я прибегал к нему в прошлом) , Иногда все, что действительно необходимо, - это тщательное изучение задействованных показателей. Наконец, стоит попробовать запросы, которые были оптимизированы с помощью этой денормализации, без ее использования, время от времени; всевозможные изменения могут устранить необходимость в этом.
Создайте отдельную таблицу для соответствующих данных, которые считаются «поиском», который не считается частью основного проекта, подчеркивая другим разработчикам, что это скорее оптимизация, чем просто плохой дизайн БД. Это также облегчает восстановление всего объекта в случае возникновения ошибки, вызывающей несоответствие, упомянутое выше.
Используйте триггеры для ведения таблицы, чтобы обновления таблиц, от которых она зависит, автоматически сохраняли правильность, вместо того, чтобы вводить специальные правила для поддержания ее при обновлении (эти правила почти наверняка будут нарушены, или по крайней мере, привести к тому, что код будет менее четким).