Лучший способ отслеживать счетчик на уровне базы данных

Я хочу отслеживать счетчик пользователей, хотя время и иметь возможность генерировать статистику об изменениях в счетчике через время.

Я довольно настроен (хотя, если они лучше, я хотел бы услышать о них) о двух основных таблицах. user и counter_change, который будет выглядеть примерно так:

user:
+-----------+------------+
| id        | username   |
+-----------+------------+
| 1         | foo        |
| 2         | bar        |
+-----------+------------+
counter_change:
+-----------+--------------------+------------+
| user_id   | counter_change_val | epoch_time |
+-----------+--------------------+------------+
| 1         | 10                 | 1513242884 |
| 1         | -1                 | 1513242889 |
+-----------+--------------------+------------+

Я хочу, чтобы показать текущее значение счетчика (с базовым значением 0) во внешнем интерфейсе, а также некоторые статистические данные через время (например: вчера ваш сетевой счетчик был +10 или -2 и т.д.).

Я подумал о некоторых возможных решениях, но ни один из них, похоже, не является идеальным решением.

Добавьте счетчик в таблицу user (или в таблицу новых counters):

Это решение кажется более эффективным с точки зрения ресурсов, во время ввода counter_change, обновлять счетчик у user с помощью counter_change_val.

Плюсы:

Получить текущее значение счетчика не потребует практически никаких ресурсов.

Минусы:

Сумма counter_changes_val может отклоняться от счетчика в user если возникает ошибка.

Не может быть действительно использован для полей статистики, поскольку для этого потребуется дополнительный запрос, и в этот момент триггер будет более удобен.

---

Добавьте вычисляемый счетчик в таблицу user (или в таблицу новых counters) в insert/update:

Это решение состояло бы из триггера SQL или некоторой функции на уровне ORM, которая обновляла бы значение вставки в таблице counter_change с суммой counter_change_val.

Это также будет использоваться для вычисленных полей, которые предполагают группировку по датам. Например, получите среднесуточные изменения за последние 30 дней.

Плюсы:

Получить текущее значение счетчика не потребует практически никаких ресурсов.

Минусы:

В каждой вставке counter_change агрегация всего текущего пользовательского counter_change.

---

Добавить просмотр или выбрать с помощью суммы счетчика

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

Плюсы:

Не добавляет полей в таблицы.

Минусы:

Поскольку он вычисляется во время выполнения, он добавляет время для запроса времени отклика. При каждом обращении к счетчику потребуется скопировать значения counter_change.