еще можно пивот сделать моделью и через нее связи  строить

ну это немного другой кейс

У меня получается есть "Раздел", в нем есть "Категории", а в нем есть "Продукты"  и вот они между собой все многие-ко-многим.
Я залепил таблицу, в которой все ключи, т.е. 3 столбца.
Ну и конечно мне надо сделать теперь выборку Раздел->Категории->продукты.
Если сразу взять Раздел->Продукты, то борода с groupBy...

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

чем раздел от категории отличается? почему не b-tree?

в разделе А может быть категоия В1, В2, В3.
в разделе А2 может быть, например В1, В3 и т.д.
тут дерево, наверное тоже не поможет

хотя.. черт его)

Всем привет. У кого есть опыт разработки сервисов email рассылки. Интересует вопрос организации БД, планировщика рассылок по кампаниям.

Есть таблицы:


subscribers (group_id | email | name)
subscribers_groups (id)
campaigns
campaigns_scheduled_overview (email | name | status | campaign_id | server_id | send_at | open_at | click_at | unsubscribe_at и т.д)


Сейчас так:

1. В рекламной кампании выбираю группу подписчиков для рассылки
2. Далее по группе подписчиков получаю получателей и добавляю в очередь на добавление в планировщик campaigns_scheduled_overview
3. Получатели добавляются в планировщик со статусом "Ожидает рассылки", далее уже работаю с таблицей campaigns_scheduled_overview (осуществляю выборку и рассылку писем

В чем вопрос: мне нужна полная стстистика по каждому получателю(ожидает, получил письмо, открыл, перешел по ссылке и т.д), на сколько так оптимально поступать (копировать получателей в промежуточную таблицу)?

Пункт 4. По идее я мог бы сразу брать получателей из таблицы subscribers, отправлять по ним письма и записывать информацию в таблицу статистики и потом ее уже обновлять,

но есть определенные НО:

1. Количество получателей больше млн.
2. Нужна очень быстрая выборка получателей, остановка рассылки, лимиты на отправку писем в СЕКУНДЫ, т.е дополнительные проверки, как следствие запросы в БД.

Вернемся к пункту 4. Если сразу брать данные из таблицы subscribers, отправлять информацию и записывать в таблицу статистики по каждой кампании,
то в случае проверки дополнительных условия (ограничение кол-ва отправок в секунды, минуты и т.д) выборка будет осуществляться из нескольких свзяанных таблиц, что по идее медленнее, чем из одной campaigns_scheduled_overview

При копировании получателей в промежуточную таблицу campaigns_scheduled_overview, выборки быстрые, но дублирование данных (получателей для каждой кампании), где компромисс? У кого есть опыт подобный? какие базы использовали и подходы?

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

прикол в версиях лары

Laravel Framework 8.15.0 . Доку читал за 8 версию и в доке эта команда есть

Ее вполне могли добавить после 8.15

Апдейтись, это минорная версия, ничего не должно поламаться

https://github.com/laravel/framework/pull/35694

Добавили после выхода 8.0

grep -r prune-batches ./vendor/
чекни, в вендоре вообще таковая имеется ли

ни чего не отобразило

А должно было что то типа

Наверное таки с версией что то

у меня 8.27.0

Я же тебе написал и даже линк на пр кинул)