Но мысль вашу понял. Это в моем сообщении изначальном был как второй вариант. Спасибо

Всем привет, как можно рассортировать роуты в разные файлы?

а как ты пытался и что не получилось?

Даже представить не могу как это сделать. В документации не нашел. Было бы удобно хранить роуты в admin.yaml и website.yaml

а где они оба подключаются?

Знал бы как их подключить, не написал бы в группе)

по запросу "symfony framework routing" не нашел ничего про admin и website, но нашел как все это говно можно рассовать по файликам

ну а хоть с admin и website получилось воспроизвести?

если чисто размыслить о предметной области, то на сеанс могут бронировать билеты, могут покупать онлайн, могут покупать бронь в момент сеанса наликом, т.о. ссылка на сеанс уже должна быть сгенерированна, само расписание редко меняется, остается непонятным почему вдруг " Бешеная нагрузка на базу при смене времени расписания" и почему у тебя события генерируются по крону, а не в каком-то мессаджере

Я вот тоже думаю что стоит разделить расписание и генерацию событий. Апдейт пары сотен строк по индексу не должно быть особой проблемой.
Да и не факт, что будет апдейт. Можно в событии держать ссылку на расписание и время тянуть оттуда. Но зависит конечно от того как меняется расписание

событие не генериться по крону, а расписание у него в виде крон строки :)
бешеная потому что это событие может повторяться как один день, раз в день, так и каждый час и целый год
+ изменения возможны
у меня около 100к юзеров в этой системе, у каждого по 3-7 таких событий. каждое событие минимум на неделю, раз в день
по скромным расчетам это уже 2 млн строк
в целом да, предген условных сеансов возможен, только с надеждой на редкие изменения

ну вот я и спрашиваю у канала идей. потому как сгенерить каждый сеанс на год вперед а потом если что сделать removeAll->regenerate при смене расписания технически можно...но как-то пока что мне это не очень идея нравится - выше описал почему

Все зависит от характера изменений. Если событие было каждый день а стало раз в неделю. Что вы делаете с уже проданными билетами?

сеанс который уже "начался" (проданы билеты или типа того) нельзя изменить

Не 2 млн строк
365 дней на 24 часа всего 8760 строк. У тебя же не все юзеров одновременно поменяют все расписания всех своих событий

про 2 млн это я имел ввиду будет в таблице если все юзеры создадут сеансы...а они создадут...такой характер системы

Значит менять будут только те, что ещё никому не проданы... Не вижу вообще проблем в решение "в лоб". Удалить пустые сеансы и сгенерить новые

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

Да, но менять ты будешь малую долю. У тебя есть индексы, чтоб бд не лопатила всю таблицу. А ещё есть партиции, но для 2 млн строк и партиции не нужны