Стоит ли хранить больше данных в бд ради упрощения sql-запросов?

Question

[Narts]

Например, есть таблица rating_history:
id
...
user_id
post_id
amount (например, +100, -12, 0)

Таблица post
id
...
category_id

Таблица category
id
name
...

Задачи:
1. Получать общий рейтинг юзера. Тут все просто - SELECT SUM
2. Получать рейтинг юзера в конкретной категории. Тут запрос будет с join-ом: к rating_history нужно будет джойнить post, чтобы добавить выборку по post.category_id

Вопросов несколько:
1. Насколько хорошая/плохая идея использовать MYSQL SUM? (таблица rating_history будет достаточно большой)
2. Насколько хорошая/плохая идея использовать MYSQL SUM и джойны?
3. Может добавить "промежуточную" таблицу: id, user_id, category_id, sum и обновлять в ней данные при инсерте в rating_history? Однако вижу тут потенциальные проблемы рассинхрона и большой размер таблицы
4. Может есть оптимальные и лакониченые решения для таких задач?

Comments

[alexalexes]

А в какие временные рамки должен уложиться запрос суммы?
Если в 200...500 мс, то париться не надо. Традиционный запрос всегда уложится в это время в рамках вашей схемы данных.
Если стоит задача получить время < 50 мс, то да, вам нужен любой инструмент кеширования, хоть средствами самой СУБД.

Answer 1

[Everything_is_bad]

SUM это нормально, пока ты укладываешься в какие-то твои установленные лимиты времен. Если не укладываешься, что начитаешь поиск узкого места и его оптимизацию, вариантов много, кеширование, денормализация и прочее. Выбор зависит от найденного узкого места, так что учись как замерять время запросов, анализировать его план, так и профилировать код. Ну и преждевременная оптимизация зло.

Answer 2

[rPman]

В зависимости от размера дополнительных данных и количества памяти, но часто да, это хорошая практика.

У меня был пример, когда рядом с огромной таблицей, я самостоятельно специальным демоном поддерживал таблицу, где в ячейках дублировал агитирующую информацию (суммы, min/max и т.п. при чем по всем моим статистическим запросам, там десятки параметров), за некоторый период (подбирать экспериментально или эмпирически по логике запросов), например по месяцам, за исключением последнего периода. Когда данных много, даже при использовании индексов, посчитать сумму за весь период по условию по всем данным - очень длительная операция. У меня было ручное разбиение исходного массива на текущий месяц и архив (это можно было делать средствами БД но мне удобнее было самому вести две отдельные таблицы) и при переносе устаревших данных в архив, велось заполнение этой агрегирующей таблицы.

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

Практика хранения часто вычисляемых данных в базе тут же рядом - очень частая.