Size: a a a

2020 September 21

NO

Nex Otaku in Laravel Pro
Sergey Pashkevich
В бд у меня хранятся записи в utc:
1 2019-09-21 20:00:00
2 2019-09-21 21:01:00
3 2019-09-22 00:00:00

Таймзона пользователя Минск +3

Пользователь хочет получить записи от 2019-09-22 00:00:00 по его таймзоне с группировкой по дням.

MySQL запрос:
select DATE(event_date) as date where event_date >= '2019-09-21 00:00:00' from sales GROUP BY date.

** event_date >= '2019-09-21 21:00:00' потому что по Минск таймзоне начало 22-го числа это в utc 21 число 21:00

В итоге я получу все три записи, но должен получить только 2 и 3.
не гуглил походу
источник

NO

Nex Otaku in Laravel Pro
источник

NO

Nex Otaku in Laravel Pro
вот я погуглил за тебя
источник

SP

Sergey Pashkevich in Laravel Pro
Спасибо) но я гуглил, но везде пишут "не уверен хорошо ли так делать", "не уверен быстро ли" и т.д. я и выше написал про это
источник

DK

Denis 🕸 Khomusyak in Laravel Pro
в условии время лишнее
источник

DK

Denis 🕸 Khomusyak in Laravel Pro
а все увидел
источник

SP

Sergey Pashkevich in Laravel Pro
Denis 🕸 Khomusyak
в условии время лишнее
время не лишнее, так как в условии по чистому полю а не сгруппированному
источник

SP

Sergey Pashkevich in Laravel Pro
Nex Otaku
вот я погуглил за тебя
и хотел бы пообщаться с людьми кто так делал и всё ли ок у них
источник

DK

Denis 🕸 Khomusyak in Laravel Pro
попробуй постучать в ru_mysql
источник

SP

Sergey Pashkevich in Laravel Pro
вот тут пишут, что это не быстрая операции в чём я и сомневался:

Making the timezone calculation in your query is indeed a way to go about that, however it might get slower and slower as your database grows. Think about it, mysql isn’t magical. For reach row in your database it will convert the date to the correct timezone and then compare it. This needs a little bit more research, but I’m not sure mysql will use the index on the “created_at” column in that situation as the index is only correct for UTC timezone.
источник

SP

Sergey Pashkevich in Laravel Pro
либо создавать материализованное представление этих данных где уже будет сгруппированная инфа по годам, дням и т.д
источник

SP

Sergey Pashkevich in Laravel Pro
но не сильно хочется держать много таблиц и поддерживать их
источник

NO

Nex Otaku in Laravel Pro
Ты представляешь как выполняется запрос SQL?
источник

SP

Sergey Pashkevich in Laravel Pro
и может я упускаю какой-то ещё из вариантов
источник

NO

Nex Otaku in Laravel Pro
Сергей
источник

SP

Sergey Pashkevich in Laravel Pro
Nex Otaku
Ты представляешь как выполняется запрос SQL?
даже не знаю что тебе ответить)
источник

NO

Nex Otaku in Laravel Pro
Смотри. Пишешь запрос. Указываешь дату начиная с которой тебя интересуют данные. Прописываешь конвертацию и группировку.

1. Сначала вычисляется минимальная дата. По ней в WHERE будут отсекаться все интересующие тебя записи.

2. Все строки по этому условию загрузятся с диска в память.

3. По загруженным в память строкам сконвертится дата в нужную time zone.

4. После этого будет группировка по GROUP BY

5. Сгруппированные данные отправляются клиенту.

Здесь нет ни лишних, ни "медленных" действий.
источник

NO

Nex Otaku in Laravel Pro
Sergey Pashkevich
вот тут пишут, что это не быстрая операции в чём я и сомневался:

Making the timezone calculation in your query is indeed a way to go about that, however it might get slower and slower as your database grows. Think about it, mysql isn’t magical. For reach row in your database it will convert the date to the correct timezone and then compare it. This needs a little bit more research, but I’m not sure mysql will use the index on the “created_at” column in that situation as the index is only correct for UTC timezone.
Здесь пишут "for each row", ты же видишь что в твоём случае никакой не "each row"?
источник

NO

Nex Otaku in Laravel Pro
Индекс у тебя и так будет использован, так как поиск записей будет по "сырому" значению TIMESTAMP.
источник

NO

Nex Otaku in Laravel Pro
То есть тупо по целому числу, так как TIMESTAMP это всего лишь количество секунд. Не знаю, что может быть быстрее и оптимальнее, чем поиск по индексу целочисленного поля.
источник