Вопрос по архитектуре БД. Собираемся писать сервис для клинингов. Таблицы юзер -

Question

Вопрос по архитектуре БД. Собираемся писать сервис для клинингов. Таблицы юзер -

адреса юзера (квартира/дом/офис) - ордера юзера.
Такой вопрос. У каждого адреса есть комнаты, по каждой комнате (кухня/аанная и т.д.) можно отдельно настраивать тип уборки. Регюляр клининг и дип клининг + есть возможность для каждой комнаты кастомизировать "доп" услуги. Типа
кухня:
-помыть духовку - да
-помыть холодильник - нет
Ванная:
-...
-...
И т.д.

У меня вопрос как хранить список этих сеттингов по каждой комнате?
Я вижу сейчас два варианта, в таблице ордера хранить json поле order_services и там складывать все опции.
Либо же мудрить что-то с таблицами. Создавать отдельную таблицу сервисов и потом связывать м2м комнаты и услуги или как то так

0

09.10.2023

11 ответов

10 просмотров

Stanislav Chernov

я бы пошёл по такому пути: таблица : объект, : - id - тип объекта (помещение/квартира/коммерческий объект/отдельное здание или что-угодно) - родитель: объект или NULL если это родительский объект - клиент - ссылка ID на клиента (чтобы можно было по 1 клиенту увидеть все объекты) - вид уборки (ссылка на таблицу с видами уборки) - группа услуг (ссылка на таблицу с набором услуг) таблица видов уборки: - id - наименование таблица групп услуг: - id - объект - к какому объекту привязана группа - список ID услуг привязанных к объекту таблица услуг: - id - название услуги -

0

7 месяцев назад

Stanislav Chernov

Stanislav Chernov
я бы пошёл по такому пути: таблица : объект, : - ...

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

0

7 месяцев назад

Daniel Daniel Автор вопроса

Stanislav Chernov
я бы пошёл по такому пути: таблица : объект, : - ...

мне еще нужно хранить по каждому объекту список комнат и их кол-во. Может быть 2 ванные комнаты и т.д. Короче говоря вообще всё не просто и запутанно получается с такими связями. Нужно хорошо продумать Но я думал в такую сторону, как ты описал

0

7 месяцев назад

Stanislav Chernov

Daniel Daniel
мне еще нужно хранить по каждому объекту список ко...

ну мне кажется тут можно в sqlalchemy сделать связь полей между таблицами и когда будете селектить object.query.all() -> то внутри будут все вложенные объекты ?

0

7 месяцев назад

Daniel Daniel Автор вопроса

Stanislav Chernov
ну мне кажется тут можно в sqlalchemy сделать связ...

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

0

7 месяцев назад

kai 3341

Daniel Daniel
мне еще нужно хранить по каждому объекту список ко...

Бля, ты прав — элементов одного типа может быть несколько, и 2 ванных тому пример. Не говоря уже о банальности о нескольких комнатах. А ещё смешнее, если не всё скажут убирать. Это увлекательный рак мозга Скорее всего, фото отчёты неизбежны. Возможно, м2м, но это не точно

0

7 месяцев назад

Stanislav Chernov

Daniel Daniel
та можно, все можно, но все выглядит запутанно. Не...

ну альтернатива - это разложить каждый вид объекта в разные таблицы

0

7 месяцев назад

Daniel Daniel Автор вопроса

kai 3341
Принципиально зависит от того, что с этими данными...

Не будет отзывов на каждый вид доп услуги. Будет оценка клинера за весь заказ. Но, ты можешь, как клиент, при создании заказа создать note и прикрепить фото по каждой опции. Например clean freezer - и у тебя там мясо которое ты не хочешь чтобы выкинули. Пишешь ноут и крепишь фотку. Если все таки хранить json поле с сеттингами, то можно в отдельной таблице хранить order_notes. Мне так кажется

0

7 месяцев назад

Stanislav Chernov

Daniel Daniel
Не будет отзывов на каждый вид доп услуги. Будет о...

А зачем имеено json? Как потом из него распарить что то в селект?

0

7 месяцев назад

Daniel Daniel Автор вопроса

можно опытных строителей призвать?) Нужен ваш совет @Tishka17 @pvlzhr ))

0

7 месяцев назад

kai 3341 · Accepted Answer

Принципиально зависит от того, что с этими данными будет дальше. Например, сегодня ОК и в json хранить. Если завтра захотят отзывы/оценки/etc на каждый вид доп услуг — тебе конец. А если у тебя постгрес с не самыми производительными JOIN — на большом числе данных с м2м тебе тоже конец По итогу есть 2 стула

Похожие чаты

Вопрос по архитектуре БД. Собираемся писать сервис для клинингов. Таблицы юзер -

11 ответов

Похожие вопросы