Сохранение статистики в течение более длительных периодов времени и времени

Question

В настоящее время я работаю над проектом, который вычисляет данные и сохраняет их по идентификатору в базе данных аналитики.

Например, количество раз, когда читается новостная статья (и поэтому есть 20 категорий данных, хранящихся как целое число).

Мы храним данные в полях, как следует: INT user_id INT value_type_id INT значение DateTime DateTime

Мы используем 4 таблицы, x_hour, x_day, x_week, x_month Таким образом, мы не должны вычислить данные в течение нескольких тысяч или даже миллионов записей.

Данные должны рассчитываться «на лету» и фильтроваться определенными соединениями. Все это не проблема и работает по назначению и со скоростью, которая является удовлетворительной.

Вопрос, который следует. Мы хотим, чтобы данные отображались в часовом поясе пользователя, который его просматривает, часовой пояс не всегда один и тот же, поскольку он может быть антиированием, например UTC-5 или UTC + 4.

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

Я читал решения, добавляя 24 столбца для хранения данных для каждого часового пояса, у любого есть другое решение.

Answer 1

Кажется, что единственный способ пойти - использовать ведра в 15 минут или точно определенные временные интервалы, из-за чего получится только около 40 столбцов.

Тогда у нас есть то же самое в течение нескольких недель и месяцев, поэтому у нас есть правильные данные для каждого часового пояса.

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

Answer 2

Продолжить хранение данных в UTC.

Передайте запрос по часовому поясу пользователя.

Преобразовать в SELECT, используя функцию CONVERT_TZ:

CONVERT_TZ(`datetimefield`, 'UTC', 'Europe/Amsterdam') 

Где Европа/Амстердам »заменяется на соответствующий часовой пояс.

Вам лучше использовать строки часовых поясов IANA, как указано выше, вместо смещений типа UTC-5, если у вас есть эти данные. Он правильно справится с проблемами, связанными с летней экономией в регионах, где это происходит.

Дальнейшие примечания: https://dev.mysql.com/doc/refman/5.5/en/mysql-tzinfo-to-sql.html - Эта программа используется для интуиции MySQL с данными о часовом поясе.