такое решение и было выбрано, теперь horizon каждый день присылает уведомления, что вот мол обратите внимание на этот воркер, так как он долго выполняется )
1) структура бд не хранит в основной таблице receipts (идентификатор из сайта А на которой можно было бы повесить индекс, он хранится в другой таблице mappings[receipt_id, external_id, ...]), а по всем остальным полям в таблице receipts могут быть дубликаты и уникальный индекс не получится
2) с очередью, понял. это конечно привнесёт доп. слой логики, но суть понял.
И всё же, а как это можно прерывать на уровне запросов? Я думал, при входящем запросе генерить уникальный хэш, по некоторым параметрам из запроса и ложить его в кэш и при каждом запросе проверять, а есть ли такой хэш. но вот запросы приходят почти в одно и тоже время и это может не успеть сгенериться и запросы пройдут без проблем
Slava Rozhnev, спасибо за ответ.
1) но запросы же приходят почти в одно время и первый запрос может не успеть положить сформированный индекс в бд или кэш
2) последовательная очередь?
К примеру у нас есть 10 уникальных продуктов. Есть 3 пользователя и каждый сформировал заявку со всеми продуктами.
и я хочу выполнить запрос с пагинацией по 10 записей на запрос. и в первом запросе я получу информацию только для одного пользователя для первого, а для остальных только в следующих запросах. и таким образом в отчёте я не смогу до конца заполнить строку для остальных пользователей
Т.е. это будет отдельная таблица в которую я буду записывать уже готовые данные по дням (если у меня "день" будет являться минимальным периодом), и она будет заполняться некой "задачей", которая будет брать прошедшие дни и заполнять эту таблицу, Вы что-то такого имели ввиду?
Понял вас, будет возможность выбора периода по event_date, но никто не исключает что пользователь выберет год, если конечно самому это не проверять и большие периоды отклонять.
А Вы не знаете как лучше поступать в таком случае и что можно сделать, чтобы всё-таки оставить выбор большого периода?
Благодарю вас за помощь. Сейчас отмечу ваш ответ правильным. А ещё вы не подскажите этот запрос с точки зрения оптимизации ну будет медленным?
Сейчас в таблице sales 500к записей, а в sale_items 800к и они быстро растут.
alex-1917, тогда это 3 вариант реализации, который не является самым лучшим.
"3 вариант - также необходима дополнительная логика на преобразования идентификаторов в названия и т.д. Если сервис перестанет работать - то и приложение перестанет корректно работать."
