Комментарии 4
Можно кстати не ставить uuid-ossp, а воспользоваться функцией gen_random_uuid, которая идёт из коробки
В далёком 2020 передо мной встала около подобная задача (тоже всё было в реальном времени, тоже есть приложение а и б, и приложение а просто пуляет данные в табличку, а приложение б их выводит)
Так вот что я сделал: добавил в таблицу куда пуляются данные параметр processed типа boolean и дефолтным значением false. В laravel просто напросто раз в минуту выбирал все записи из этой таблицы с помощью cron учитывая параметр processed, совершал всяечкие манипуляции (обновлял смежные таблицы, парсил данные) а после ставил processed true и всё
Решение далось намного быстрее без всяких заморочек, интересно услышать ваше мнение и почему не сделали так же
cron, а следовательно и планировщик Laravel, минимально "тикают" раз в минуту. Такое время отклика оказалось неприемлемым. В качестве альтернативы можно запустить некий процесс, который будет отслеживать состояние базы данных чаще. Но событие X в приложении А случается не часто, но отклик на него должен быть незамедлительным. Поэтому мне показалось разумнее поставить задачу в очередь, чем постоянно опрашивать БД.
Постановка задачи (Job) в очередь Laravel из хранимой процедуры или триггера PostgreSQL