Как посоветуете хранить данные?

Question

[KirSupi]

Задача такая:
Обычная БД MySQL на обычном хостинге
Есть некоторое кол-во пользователей (>200)
У каждого пользователя есть

некоторые данные

# пример данных:
"user10" : {
    "way": 15,
    "trees": 10,
    "songs": 7
}

Причём всё это надо кешировать по датам, т.е. надо хранить данные конкретного пользователя в конкретный день, чтоб при необходимости можно было их вытащить для скрипта php/python
Бекендом и бд особо никогда не занимался, так что в голову не приходит ничего лучше, чем создать в бд таблицу cashed_data и в ней два столбца - date и data, и в date записывать, например, "2021-07-04", а в data записывать json со всеми данными всех пользователей.
Может, посоветуете, как было бы проще и удобнее хранить всё это?

Comments

[FanatPHP]

Зачем так сложно-то?
тупо таблица
юзер, дата, way, trees, songs

это если ты полностью описал свою структуру данных, а не огрызок из неё

[KirSupi]

FanatPHP, иногда надо через php условно "взять все вчерашние данные по всем пользователям и к каждому добавить +1 way". Мне как-то интуитивно кажется (креститься надо), что лучше сделать один запрос к бд для всех сразу, вместо неимоверного кол-ва запросов для каждого юзера.

[hint000]

KirSupi, вот как раз так, как предложил FanatPHP, вы одним запросом и сделаете (достаточно хоть немного почитать про SQL, самые основы). А представьте, что вам надо добавить одному пользователю, но за месяц - и будете 30 кусков json обрабатывать вместо одного простого SQL-запроса?

[hint000]

KirSupi, если не изучать SQL, тогда уж лучше полностью json обойтись и не связываться вообще с SQL, а то ситуция с json внутри SQL напоминает Чебурашку: https://www.youtube.com/watch?v=diKuiBi8DvE

[KirSupi]

hint000, насчёт Чебурашки согласен)

полностью json обойтись

Как-то многовато хранить, нет? Если за полгода брать, а каждый день минимум по 200 пользователей

[raiboon]

json уже давно стал first-class citizen в популярных реляционных бд, хватит его бояться.

[FanatPHP]

KirSupi, да, конечно лучше сделать одним запросом
а в чем проблема?

[FanatPHP]

raiboon, это не значит что надо выкинуть все нормальные данные и оставить один джейсон
в данном случае он тут нафиг не нужен

first-class citizen в любой базе - это думать, желательно мозгами. а не бегать за хайпом
у джейсона есть своя ниша. узкая. в частности заменять кошмарный eav.
но просто так, за здорово живешь, отказываться от контроля целостности данных на уровне БД будет только тот, для кого база данных кончается на файлике со списком учеников 5 класса "бэ"

[KirSupi]

FanatPHP, просто опасаюсь, что слишком много запросов придётся делать к каждому юзеру по отдельности, вместо одного запроса
Плюс записей в таблице будет сильно больше (условно говоря, в 200 раз, если 200 пользователей)
И за полгода будет уже 37к записей, среди которых надо будет постоянно искать нужную

[FanatPHP]

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

[KirSupi]

FanatPHP, самый простой пример:
Надо посчитать суммарное кол-во way всех пользователей за определённый день

[FanatPHP]

ты вообще помнишь, о чем сам говорил час назад?
я не спрашиваю, что тебе надо сделать
я спрашиваю откуда при решении этой задачи возьмется "слишком много запросов"?

Answer 1

[hint000]

Пихать json внутрь SQL - это дичь; выберите либо одно, либо другое.
Если названия полей не фиксированные, тогда так:
date user var val
--------------------------------
2021-07-04 user10 way 15
2021-07-04 user10 trees 10
2021-07-04 user10 songs 7

https://en.wikipedia.org/wiki/Entity%E2%80%93attri...

Comments

[FanatPHP]

вот еав тут никаким боком, если набор фиксированный.

[hint000]

FanatPHP, дыкъ я же и пишу: "если не фиксированные". Из постановки задачи это не ясно.

[Dimonchik]

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