Почему люди сохраняют количество X в столбце новой базы данных?

Question

Давайте представим, что есть три таблицы - 'users', 'products' and 'faves'.В пользовательской таблице хранятся все пользователи с чем-то вроде 'id', 'username', 'email';в 'products': 'id', 'name', 'price'; in 'faves': 'id', 'product_id' (идентификатор продукта, связанный с 'products'), 'user_id' (идентификатор пользователя, добавившего лайк, связанный с 'users'), 'modified_on'.Это фиктивный пример, созданный только для иллюстрации того, о чем я говорю ... (:

Я часто вижу, что есть еще один столбец для таблицы 'products'. Он называется 'count_of_faves' или что-то в этом роде.Зачем это нужно? Я имею в виду, что можно легко подсчитывать фаве для указанного поста, как на лету, верно? Это как-то связано со скоростью их подсчета, когда данных очень много?

Дополнительный вопрос:

Есть ли лучший, более автоматический способ сделать +1 и -1 для count_of_faves, чем каждый раз при создании нового запроса, который обновляет эту строку?

Answer 1

В крупномасштабной системе вы можете сэкономить много времени на обработку, быстро извлекая count_of_faves вместо необходимости пересчитывать агрегат COUNT() в некотором наборе строк каждый раз, когда вам это нужно. Если бы вы, например, отображали count_of_faves на каждой странице, вам нужно было бы каждый раз пересчитывать его или где-нибудь кэшировать. Вы можете кэшировать его в коде своего приложения, например, в сеансе, или вы можете кэшировать его в базе данных.

Кэширование в базе данных имеет несколько преимуществ - при создании отчетов о ваших данных за пределами кода приложения значения легко доступны для использования.

Операция:

UPDATE table SET count_of_favs = count_of_favs + 1 WHERE id='whatever';

гораздо дешевле выполнить, чем пересчитывать совокупность COUNT() все время.

Answer 2

Это оптимизация, сделанная для уменьшения количества выполненных СЧЕТОВ, где может быть большое количество отношений. Возьмем, к примеру, если число 'faves' невелико, выгода ограничена и, возможно, отрицательна (так как счет должен обновляться каждый раз, когда 'fave' создается или уничтожается).

Но если счетчик читается гораздо чаще, чем изменяется при добавлении / удалении отношений, сохранение значения становится эффективной стратегией кэширования.