адреса юзера (квартира/дом/офис) - ордера юзера.
Такой вопрос. У каждого адреса есть комнаты, по каждой комнате (кухня/аанная и т.д.) можно отдельно настраивать тип уборки. Регюляр клининг и дип клининг + есть возможность для каждой комнаты кастомизировать "доп" услуги. Типа
кухня:
-помыть духовку - да
-помыть холодильник - нет
Ванная:
-...
-...
И т.д.
У меня вопрос как хранить список этих сеттингов по каждой комнате?
Я вижу сейчас два варианта, в таблице ордера хранить json поле order_services и там складывать все опции.
Либо же мудрить что-то с таблицами. Создавать отдельную таблицу сервисов и потом связывать м2м комнаты и услуги или как то так
Принципиально зависит от того, что с этими данными будет дальше. Например, сегодня ОК и в json хранить. Если завтра захотят отзывы/оценки/etc на каждый вид доп услуг — тебе конец. А если у тебя постгрес с не самыми производительными JOIN — на большом числе данных с м2м тебе тоже конец По итогу есть 2 стула
я бы пошёл по такому пути: таблица : объект, : - id - тип объекта (помещение/квартира/коммерческий объект/отдельное здание или что-угодно) - родитель: объект или NULL если это родительский объект - клиент - ссылка ID на клиента (чтобы можно было по 1 клиенту увидеть все объекты) - вид уборки (ссылка на таблицу с видами уборки) - группа услуг (ссылка на таблицу с набором услуг) таблица видов уборки: - id - наименование таблица групп услуг: - id - объект - к какому объекту привязана группа - список ID услуг привязанных к объекту таблица услуг: - id - название услуги -
+ наверно я бы еще учитывал дату начала и дату окончания групп услуг, т.к. сегодня нужно один набор - а завтра уже другой
мне еще нужно хранить по каждому объекту список комнат и их кол-во. Может быть 2 ванные комнаты и т.д. Короче говоря вообще всё не просто и запутанно получается с такими связями. Нужно хорошо продумать Но я думал в такую сторону, как ты описал
ну мне кажется тут можно в sqlalchemy сделать связь полей между таблицами и когда будете селектить object.query.all() -> то внутри будут все вложенные объекты ?
та можно, все можно, но все выглядит запутанно. Не хочется потом упереться в один прекрасный момент в производительность и в гигантские запросы. Буду еще с ребятами общаться кто как видит это
Бля, ты прав — элементов одного типа может быть несколько, и 2 ванных тому пример. Не говоря уже о банальности о нескольких комнатах. А ещё смешнее, если не всё скажут убирать. Это увлекательный рак мозга Скорее всего, фото отчёты неизбежны. Возможно, м2м, но это не точно
ну альтернатива - это разложить каждый вид объекта в разные таблицы
Не будет отзывов на каждый вид доп услуги. Будет оценка клинера за весь заказ. Но, ты можешь, как клиент, при создании заказа создать note и прикрепить фото по каждой опции. Например clean freezer - и у тебя там мясо которое ты не хочешь чтобы выкинули. Пишешь ноут и крепишь фотку. Если все таки хранить json поле с сеттингами, то можно в отдельной таблице хранить order_notes. Мне так кажется
А зачем имеено json? Как потом из него распарить что то в селект?
можно опытных строителей призвать?) Нужен ваш совет @Tishka17 @pvlzhr ))
Обсуждают сегодня