Comments 4
Вы путаете денормализованные данные и переопределённые данные. И рассказываете именно о переопределении - т.е. о введении дополнительных полей, которые содержат данные, которые могут быть вычислены на основании других данных. Денормализация же предполагает отсутствие переопределения - т.е. никакие данные таблиц не могут быть точно вычислены на основании других данных.
Ну и как-то некрасиво вот тут: "Есть сложная связь многие-ко-многим между Products и Categories." - а дальше в коде идут таблицы курсов и студентов.
Денормализация, как вы заметили, не всегда включает переопределение данных. Однако, в некоторых контекстах, добавление вычисляемых полей может быть частью стратегии денормализации, особенно когда это способствует уменьшению сложности запросов и в целом при работе с базами данных
Часто нам приходилось включать добавление вычисляемых полей для оптимизации производительности и упрощения запросов
Насчет правки во втором абзаце спасибо. Действительно, изначально планировался другой пример и забыли поправить
Денормализация, как вы заметили, не всегда включает переопределение данных.
Вот вообще не понял, что имеется в виду. Есть переопределение. Есть денормализация. Обе эти штуки - они сами по себе, и друг от друга не зависят, как говорится, от слова "совсем". Хотя да, могут присутствовать одновременно.
добавление вычисляемых полей может быть частью стратегии денормализации
Вычисляемые поля - это НЕ денормализация, и никакого к ней отношения не имеет. Они вообще не являются частью набора данных, потому что их как самостоятельного объекта (сущности или атрибута сущности) - не существует. По большому счёту их и переопределением-то считать нельзя было бы, не существуй возможность делать их STORED. Это скорее синтаксический сахар, чем что-то ещё.
К вышесказанному можно добавить что важна не только нормализация/денормализация данных в базе, а принципы работы/построения самого прикладного приложения для работы с БД. :-)
К примеру (очень условно) ваши данные БД нормализованы и на одну запись DATA1 в одной таблице приходится тысячи связанных записей c DATA2 в другой таблице.
Задача выбрать и к примеру посчитать количество записей с диапазоном значений в DATA1.
Оптимальное решение такой задачи выборка из БД только записей по условию из первой таблицы и выдача итогового результата.
Вот только прикладной разработчик решил что ему "удобнее" оперировать "объектом" и в каждой таблице лежат его "свойства/параметры". Что бы получить "желаемое" программист делает GetObject (читая ВСЕ свойства своего "объекта" из двух таблиц), а после уже делает анализ нужного параметра (DATA1) с анализом необходимого условия.... :-) Как то так...
Обратная нормализация (денормализация)