это расписание на дни

каждый день разное время

старые архивировать

зачем что-то архивировать?

10к записей с учетом что все пришли днем это всего 833 записи в час

чтобы не хранить в базе уже не нужные записи

я не понимаю в чем паника

Проблема не в час

Да не, проблема же, что в бд в которой например 50 миллионов записей выборку сделать

будет тормозить нет?

хз

Просто с ростом клиентов будет табличка timetable заполняться быстрее

зависит от множества факторов

timetable фиксированные для каждого клиента?

если будет тормозить тогда делать архивацию старых

но для постгреса 50М записей это норм Если индексы правильные

timetable на каждое кафе например каждого клиента

на каждое время

да 50 миллионов реально набрать за 3-6 месяцев

если писать каждое время как запись в бд

надо обходить

хранишь timetable для клиентов в одной таблице и занятые слоты в другой

надо писать только где бронь прошла

ну я про слоты и говорю

я предлагаю дорости хотябы до 5м записей, а потом уже решать проблему

я предлагаю дорости хотябы до 5м записей, а потом уже решать проблему

++

у меня 4,7м записей, я подумываю, но пока забиваю

у меня подобную штуку люди за неделю 10к набили

а они еще не начали работать

будет 5м поговорим

и это только тестовые свои забили

ок

Да я не спрашиваю как оптимизировать запрос

у меня тестовые сделали 200к

я просто не понимаю, зачем хранить старые записи, которые не актуальны?

50_000_000 / (24*4) = 520_000 клиентодней

я просто не понимаю, зачем хранить старые записи, которые не актуальны?

дата майнинг

Я спрашиваю сильно ли я потеряю если буду сравнивать дефолтный календарь с бронями на неделю и мержить их находу

(я не думаю что гранулярность будет меньше 15 минут

нет, не сильно

а что такое гранулярность?

минимальная длина брони

это отраслевая какая-то фигня?

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

ну наверное

да влюбом случае, преждевременная оптимизация плохо

постфактум тоже плохо

я просто не понимаю, зачем хранить старые записи, которые не актуальны?

скинь доки по архивированию записей

надо вовремя оптимизировать

да влюбом случае, преждевременная оптимизация плохо

это да. Но вопрос в архитектурном решение а не оптимизации

я же не спрашиваю как быстрее отрендерить хелло ворлд

через реакт компонент или js.erb паршиал

я бы делал через erb

erb переверстать в реакт проще когда бизнес готов

я бы не нанимал фронта пока бизнес не перейдет на самоокупаемость вообще

скинь доки по архивированию записей

ну ты просто берешь тонну записей и экспортишь из бд а при надобности заносишь обратно

вот тут или я создам табличку и буду генерить на неделю вперед слоты под время или я сделаю календарь и на его основе буду мержить в него брони и выдавать юзеру

давай созвонимся в понедельник, я протрезвею

ну ты просто берешь тонну записей и экспортишь из бд а при надобности заносишь обратно

но вообще это нафиг не нужно и не пригодится, потому что проще сделать partitioning

я теряю секунду примерно на sypex геолокации

а там только определие гео и я на сторону не звоню, на ходу из файла читаю

вот и 2 запроса плюс возня с массива не отнимет ли время

тут большая проблема — как версионирование расписаний прикрутить

не будет ли дольше чем простая выбора в миллионой бд

сколько клиентов, сколько секунд потерь на клиента?

потому что при смене расписания будет геморрой

это да

ERROR: S client not available

расписание будет изначально дефолтное

на 1 неделю

далее 1-2-3-4 неделя месяца

из расписания беру время, дату и прайс

и по умолчанию она is_free: true

вот я ее получаю и рендерю

Если юзер выбрал время и записался

то я планирую получать это расписание

получать на неделю вперед бронь для текущего «кафе»

и рендерить расписание и если время занято то is_free: false

придется повозится с массивами на ходу, но тогда у меня не будет кучи ненужных записей

решить только версионность расписания

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

и в итоге если мой клиент работает с версией 2 например то для нее тянуться в2 брони

я вчера весь вечер гуглил и таймслот это боль еще та

time_table "version, client_id, day_of_week(0-6), time (interval), price" timetable_version "client_id, start_time, finish_time" bookings "time_table_id customer_id date"

Это канает в гостинице, там нету расписания. Там юзер их создает.

джойнишь time_table с bookings за дату — получаешь все данные для расписания

единственная проблема — в дату перехода с версию на версию нужно будет что-то костылить

да

но если время перехода с начала суток — никаких проблем

время перехода сначало суток

таймзона одна?

Нет

тогда с начала часа

но тоже ок

Но это не важно. Мы пишем и понимаем все относительно города в котором бронь

Поэтому если кафе создается для екб например

то и время брони ЕКБ понимают

лучше так не делать, ибо у регионов бывает изменение таймзон, например

о переходе на летнее/зимнее время, благо, беспокоится не стоит если только РФ

ну я нахожусь в екб и когда забиваю я пишу в 10 утра например