Как писать данные на каждый день в статистику — дублировать или пропускать?

Question

[Вова Дружаев]

Пишется статистика на каждый день.
Структура:

date             | type   | num
2020-04-06 | rating | 384

Событий получается штук 40-к и некоторые события не меняются ежедневно.
Вопрос - стоит ли писать такие данные в БД на каждый день?

Пример: тип rating. Вчера он был = 384, сегодня также 384 - получается я забиваю неизменяемые данные и нарушаю принципы DRY.

Но если я буду писать только измененные данные - я не понимаю как мне получить выборку из базы.

SELECT * 
FROM `site_statistics` 
WHERE type = 'rating'
AND date = '2020-04-06'

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

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

Или все же не стоит заморачиваться и каждый день писать одно и тоже значение в базу?

Тогда там может быть:
2020-04-06 | rating | 384
2020-04-05 | rating | 384
2020-04-04 | rating | 384
2020-04-03 | rating | 384
2020-04-02 | rating | 384
2020-04-01 | rating | 384
2020-03-31 | rating | 384
2020-03-30 | rating | 360

Напомню: что пока событий 40-к и есть вероятность что их будет больше.

Answer 1

[ThunderCat]

если вчера была температура 27 градусов, и сегодня 27, может метеорологам не стоит записывать каждый день температуру?
Естественно писать, если эти параметры относятся к логированию и построению какой-либо статистики, и к DRY это никаким боком не относится.

Comments

[Вова Дружаев]

а может метеорологи не дублируют? А выводят данные (одинаковые же) из ближайшего по дате с таким же значением. А в интерфейсе пользователю все равно откуда это значение - все показано верно.

DRY - это не повторяться. Я вижу по десятку событий что я их неделю пишу одни и те же и повторяюсь. Или MYSQL принципы боком?

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

[ThunderCat]

Владимир Дружаев,

DRY - это не повторяться.

То есть обычно вы дальше заголовка не читаете... Найс...

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

[Вова Дружаев]

Ваш ответ я услышал, спасибо

[kafkiansky]

При чем здесь dry до логов и статистики? Возьмем среднее арифметическое оценок в классе: 7 человек получили четверки, двое получили 5, еще 9 получили 3. Вы запишете только 3 оценки, потому что dry? Ну бред воспаленного разума же. Логи есть логи, никакого отношения принципы проектирования классов/функций к базе не имеют. Давайте еще наследование таблиц сделайте.

[Вова Дружаев]

kafkiansky не пишите в комментариях. Напишите ответом - пообщаемся по вашему мнению.
У меня конкретный случай. С оценками в школе (ваш конь в вакууме) не имеет общего.

Под ответом ниже (nokimaro) уже есть результаты.

[ThunderCat]

kafkiansky,

проектирования классов/функций к базе не имеют.

Справедливости ради - имеют, но носят совершенно иной смысл нежели его пытается пропихнуть ТС.

[Вова Дружаев]

ThunderCat, я не "пропихиваю", а спрашиваю совета - "дублировать или пропускать"
Передёргивать не надо. Это площадка не для ехидства - а для обмена опытом.

Буду рад если посмотрите на комментарий ниже с примером по UNION

[ThunderCat]

Владимир Дружаев, вы как-то странно не пропихиваете. Уберите из вопроса DRY, он там действительно не к месту, в частности по этому у вас некоторая каша в голове, и я понимаю что это больше от неопытности, а не от тупости или из вредности. Еще раз - логи не являются дублированием, каждая запись отображает единственную уникальную сущность с привязкой по времени. То есть идущие подряд повторяющиеся значения это норм. Есть ОЧЕНЬ много аргументов за, и есть всего 2 (неверных) против:
1) Мы делаем не по DRY (достаточно прочитать и минуту подумать, чтобы понять что это не так)
2) Мы экономим место (экономия на спичках, которая оборачивается повышением сложности системы на несколько уровней сразу)

И да - снизу решение, которое решает задачу, которую мы героически себе создали сами. Юнион не "бесплатная " операция, сильно добавляющая просадки как по памяти, так и по цп. То есть кроме того что система у нас теперь неконсистентна (не на каждую дату есть значения), есть еще нехилый оверхед по вычислениям.

[Вова Дружаев]

Не обращайте внимание на DRY, читайте как "дублирование"
Можно и не принимать близко к сердцу слово Лог.
Эту систему можно охарактеризовать как система записи изменений. Так тогда проще выйдет понимание?

Есть данные. Когда они изменились - их пишем. Если у нас на 6 апреля нет записи измененных данных - берем последнее значение (по дате раньше) и пишем что на 6-е число оно было равно 384

[ThunderCat]

Владимир Дружаев,

"дублировать или пропускать"

вот, тут у вас основная ошибка. Вы не дублируете, а записываете состояние. Как минимум дата изменилась. То есть вместо просто внесения в лог сущности, вы сначала проверяете есть ли изменения ( + 1 операция), потом записываете, потом при извлечении вычисляете какие даты пропущены (+ 1 операция) и потом вытаскиваете предыдущие (+ 1 операция). Найс?

[Вова Дружаев]

ThunderCat, хорошо, согласен. Спасибо за ответ. Посмотрю на другие ответы

[Вова Дружаев]

Ещё раз спасибо за ответ.
Не стал исключать и пишу все события на каждый день.

Answer 2

[nokimaro]

Пишите каждый день. С принципами DRY это не имеет ничего общего.
Если задача хранить итог за каждый день, то его надо записывать и хранить.

каким-то образом подзапросом найти последнее значение типа

Делать это в приложении, а не в БД. Выстраивается временная шкала в приложении (напр. массив со списком дней), где есть каждый нужный день, и на неё накладываем данные из БД последовательно, если данных нет то выводим или ноль или крайнее значение.

Comments

[Вова Дружаев]

вопрос - как получить эффективно это крайнее значение сразу при запросе по нужной дате (подзапросом возможно?)

[nokimaro]

Владимир Дружаев, могу только подсказать как заполнить пробелы в датах, то есть чтобы в выборке с пропущенными днями, эти дни появились, но значение rating будет 0.

До MySQL 8 эта задача решалась путём создания вспомогательной таблицы со всеми нужными днями. Этакий календарь-список на 10 лет вперёд.

В MySQL 8 подвезли Recursive Common Table Expressions и можно такие "календари" генерить на лету и join'ить в запрос.

Но в любом случае оптимальным способом такое решать - сделать логику в приложении. Так как получите максимально эффективный запрос к БД с минимумом данных, а решение на чистом SQL вряд ли будет отличаться производительностью.

[Вова Дружаев]

Посмотрите этот запрос:

(SELECT * 
FROM `site_statistics` 
WHERE type = 'rating'
AND date = '2020-04-05') 
UNION 
(SELECT * 
FROM `site_statistics` 
WHERE type = 'rating'
AND date < '2020-04-05'
ORDER BY date DESC
)
LIMIT 1

Я получаю данные - если первый запрос не прошел - то ближайшее значение по этому событию. Но верный ли это подход? или каким-то образом IF использовать - но у меня с ним не получилось

[Вова Дружаев]

Спасибо за ответ ранее.
Не стал исключать и пишу все события на каждый день.