Денормализовать живые данные ради отчетов - Хороший или Плохой?
Для сложных объектов, которые приведут к определенным сравнениям, затем реализовывая IComparable и определяя сравнение в Сравнить методах, хорошая реализация.
, Например, у нас есть объекты "Механизма", где единственной разницей может быть регистрационный номер, и мы используем это для сравнения, чтобы гарантировать, что математическое ожидание, возвращенное в тестировании, является тем, которое мы хотим.
6 ответов
Денормализация ради отчетов - это плохо, пожалуй.
Создание представлений или хранилище денормализованных данных - это хорошо.
Представления решили большинство моих потребностей, связанных с отчетами. Хранилища данных хороши, когда пользователи будут создавать отчеты почти постоянно или когда ваши просмотры начинают замедляться.
Вот почему вы хотите нормализовать свою базу данных.
- Чтобы освободить коллекцию отношений от нежелательных зависимостей вставки, обновления и удаления;
- Уменьшить потребность в реструктуризации коллекции отношений по мере введения новых типов данных и, таким образом, увеличить срок службы прикладных программ;
- Сделать реляционную модель более информативной для пользователей;
- Сделать набор отношений нейтральным по отношению к статистике запроса, где эта статистика может изменяться с течением времени.
—ЭФ Кодд, «Дальнейшая нормализация реляционной модели базы данных» через wikipedia
Единственный раз, когда вам следует рассмотреть вопрос о де-нормализации, - это когда время, необходимое для создания отчета, неприемлемо. Денормализация вызовет проблемы согласованности, которые иногда невозможно определить, особенно в больших наборах данных
Не денормализуйте только для того, чтобы избавиться от сложности отчетности, это может вызвать огромные проблемы в остальной части приложения. Либо вы не применяете правила, приводящие к неверным данным, либо если вы это сделаете, то вставка, удаление и обновление могут быть серьезно замедлены для всех, а не только для двух или трех человек, которые создают отчеты.
Если отчеты действительно не могут запускаться хорошо, затем создайте денормализованное хранилище данных и заполняйте его еженедельной или ночной лентой. Типы отчетов, которые обычно нуждаются в этом, обычно не заботятся о том, являются ли данные актуальными, поскольку они обычно представляют собой ежемесячные, квартальные или годовые отчеты, которые обрабатывают (и особенно агрегируют) большие объемы данных постфактум.
Еще один недостаток заключается в том, что данные, скорее всего, не будут отображаться в реальном времени, так как для перехода от нормализованной формы к ненормализованной требуется некоторое время. Если кто-то хочет, чтобы отчет был до той самой секунды, когда он был запрошен, это может быть сложно сделать в этой ситуации.
Если это дублирование синхронизации в исходном сообщении, извините, я не совсем его увидел туда.
Можно сделать и то, и другое... пусть нормализованная база данных для приложений. Затем создать денормализованную базу данных для отчетов и создать приложение, которое будет регулярно копировать данные из одной базы данных в другую.
В конце концов, отчеты не всегда должны иметь самые последние обновленные данные, в большинстве случаев вы можете легко запустить обновление каждые 1 час в отчетной базе данных, и только один раз в день.
За пределами хранилища данных и представлений решения, представленные в других ответах, которые являются хорошими в некотором роде, если вы готовы пожертвовать некоторой производительностью, чтобы получить хорошие данные до последней секунды, но все же хотите нормализованную базу данных, вы можете использовать на Oracle Материализованное представление с быстрым обновлением при коммите, или в Sql Server, вы можете использовать кластерные индексы для представления.