Данные в БД: Когда денормализовать, а когда кешировать?

однозначных ответов на такие вопросы нет.

все зависит от того, что «дороже» и насколько критичны точные данные.

если пытаться обеспечить на 100% точные и актуальные данные, то на каждый апдейт исходных данных прийдется пурджить кеш либо пересчитывать денормализованные данные. при таком раскладе, стоит выбрать тот вариант которые менее «compute intensive», то что быстрее — вставить дополнительные данный либо обновить кеш. в большинстве случаев, стоимость будет приблизительно одинаковой, и тогда без разницы какой метод использовать. дело вкуса, я как best practice предпочитаю денормализацию, в нее легче и «прозрачнее» потом руками залезть админам в продакшене в случае чего.

если же 100% точность обеспечивать необязательно, а это очень часто так бывает, то однозначно лучше кеш, потому что его можно обновлять реже. твой пример с рейтингом комментариев имхо именно такой (про вестинг я не понял). только надо хорошо продумать стратегию обновления кеша — когда, сколько, по событию или по таймеру, или какая-то комбинация факторов. важно всегда обеспечивать механизм работы с кешем «для людей», а также очень качественно все эти механизмы и решения документировать, опять-таки для продакшена.

В первом (очень грубом) приближении, если кеш не устаревает исключительно по таймауту, надо трижды подумать, стоит ли его использовать. Рискуете получить все «прелести» денормализации + дополнительный гимор от размазывания данных и кода.

Все зависит от правил обновления.

Во всех приведённых примерах надо использовать денормализацию. Плюсы оной: персистентность и возможность задействовать де нормализованные данные в запросах.

Кешировать - поле полностью денормализированных данных слишком велико, но определенные запросы вероятнее других.

Денормализация - денормализировать физически возможно и пользователь практически равновероятно пользуется всем полем данных

Во-о-от. Когда стОит использовать денормализацию (например, некий процесс в фоне будет всё вычислять и сохранять в базу)

ты точно уверен, что это «денормализация»? Может следует сначала изучить, что такое «нормализация»?

С т.з. теории, то, что ты называешь «денормализация», это и есть кеширование, только не самое примитивное, а с вычислением чего-то.

Очевидно, в общем случае эффектность твоей «денормализации» считается как и эффектность простого кеширования.

Да ты прав.

А как бы ты решал такую задачу:

• У тебя в БД есть акции. Акции характеризуются следующими параметрами, которые используются для вычисления «стоимости» акции (стоимость зависит от даты - дорожает со временем):
  • Дата выпуска;
  • Стоимость;
  • Интервал повышения стоимости;
  • Величина повышения стоимости;
  • Дата досрочного окончания повышения стоимости (опционально);
  • Дата окончания повышения стоимости;
• Т.е., например, есть акция A, которая выпущена сегодня и стоит 1 р., через месяц будет стоить 2 р., а через два - 3 р. После этого повышение её стоимости прекратится. Повышение так же может прекратиться досрочно.
• Имеется дофига групп людей, в каждой группе - много пользователей, у каждого пользователя - много таких акций.
• Требуется отображать инфу о том, сколько сейчас стоят все акции определенной группы, определенного пользователя; какие акции имеются у группы, у пользователя, и т.п.

Пример:

• Компания «ЛОР INC»;
• Пользователи - макском, стивджобс, анон;
• Акции
  • Макском: 1) сегодня - 1 руб., ежемесячно увеличивать на 5 руб., до 2015 года; 2) месяц назад - 10 руб., ежедневно увеличивать на 1 руб, до лета /досрочно остановлено вчера/; 3) ...
  • Стивджобс: ...
  • Анон: ...
• Какова стоимость акций всех пользователей «ЛОР INC» на сегодня?
• Какова текущая стоимость всех акций Макскома? Стиви?