Проблема дублированных данных является сложной в реляционных базах данных.Если ваше приложение выполняет модификации данных, то дублированные данные вызывают проблемы с синхронизацией - данные необходимо обновлять в нескольких местах.
Это плохо по ряду причин:
- Обновление одного элемента информации требует нескольких изменений.
- Несколько изменений могут быть несинхронизированы, что означает, что запросы не будут видеть непротиворечивые данные.
- Изменения в структуре базы данных (например,Добавление новых таблиц) может быть довольно громоздким.
Базы данных do поддерживают эту возможность через свойства ACID, транзакции и триггеры.Тем не менее, они добавляют накладные расходы.В общем, такое дублирование добавляется по необходимости (т.е. производительности), а не заранее.Следовательно, существует строгое предпочтение для нормализованных моделей данных, в которых информация сохраняется только один раз, когда часто происходят обновления.
С другой стороны, некоторые базы данных используются в основном для запросов.Эти базы данных часто денормализованы - и это так.Например, таблица клиентов может содержать сводки по многим различным измерениям, собирая информацию из десятков базовых таблиц.
Это не только упрощает запросы, но и кодирует бизнес-логику .Одна из основных проблем с использованием данных заключается в том, что разные люди имеют немного разные определения вещей - это годовой клиент, который начал 365 дней назад?Кто-то, кто начал в тот же день в прошлом году?Кто-то, кто был вокруг в течение 12 месяцев?Стандартизированные таблицы анализа дают ответ.
Кажется, ваш случай больше относится к первой ситуации.Вы делаете обновления и думаете о сохранении резюме заранее.Я бы отговорил вас от этого.Просто напишите запросы, необходимые для обобщения данных.По всей вероятности, индексы и секционирование обеспечат всю необходимую вам производительность.
Если вы заранее знаете, что миллионы пользователей пройдут сотни опросов с десятками вопросов, то вы можете подумать о производительности.оптимизация заранее.Но для тысяч пользователей, принимающих несколько тестов с несколькими десятками вопросов, начните с простой модели данных и сделайте ее более сложной после того, как вы продемонстрировали, что она работает .