Как правильно спроектировать данную «махину»? Делаю сайт доставки еды.
Клиенты делают заказ. Заказ может быть одиночный (single) и совместный (joint).Одиночный заказ - ничего особенного, строка в БД с колонками ID, заказчик, стоимость, статус и т. д.Совместный заказ - заказ, который делают несколько клиентов, они объединяются в так называемые "группы" - там у них есть чат, там они видят с кем они заказывают еду, видят статус заказа, цену и т. д. Совместные заказы также суются в таблицу orders с пометкой "совместный"
Сайт работает только через rest API. Схема заказа такая:POST запрос на /orders для создания заказа. Юзер передает товары которые хочет заказать и тип заказа - single или joint.Сервер сует заказ в таблицу orders и возвращает 201.Юзер начинает делать периодические запросы на GET /orders/current для обновления инфы о заказе
Все понятно с одиночным - строка в БД с заказом и все. А с совместными все сложнее - там несколько пользователей. Допустим, 3 пользователя объединены в одну группу. Получается, что в таблице orders три одинаковых строки (только ID создателя отличаются). Вдруг статус заказа поменялся - и мне нужно сейчас у этих 3 строк статус обновить? Как-то некрасиво получается.
У меня есть решение этой проблемы - создать вообще другую сущность Group которая никак не пересекается с Order. Или есть более адекватное решение?
Надеюсь, вы поняли мой вопрос) Пишите, если что-то непонятно в тексте вопроса)
Как правильно спроектировать данную «махину»? Делаю сайт доставки еды.
Клиенты делают заказ. Заказ может быть одиночный (single) и совместный (joint).Одиночный заказ - ничего особенного, строка в БД с колонками ID, заказчик, стоимость, статус и т. д.Совместный заказ - заказ, который делают несколько клиентов, они объединяются в так называемые "группы" - там у них есть чат, там они видят с кем они заказывают еду, видят статус заказа, цену и т. д. Совместные заказы также суются в таблицу orders с пометкой "совместный"
Сайт работает только через rest API. Схема заказа такая:POST запрос на /orders для создания заказа. Юзер передает товары которые хочет заказать и тип заказа - single или joint.Сервер сует заказ в таблицу orders и возвращает 201.Юзер начинает делать периодические запросы на GET /orders/current для обновления инфы о заказе
Все понятно с одиночным - строка в БД с заказом и все. А с совместными все сложнее - там несколько пользователей. Допустим, 3 пользователя объединены в одну группу. Получается, что в таблице orders три одинаковых строки (только ID создателя отличаются). Вдруг статус заказа поменялся - и мне нужно сейчас у этих 3 строк статус обновить? Как-то некрасиво получается.
У меня есть решение этой проблемы - создать вообще другую сущность Group которая никак не пересекается с Order. Или есть более адекватное решение?
Надеюсь, вы поняли мой вопрос) Пишите, если что-то непонятно в тексте вопроса)
Клиенты делают заказ. Заказ может быть одиночный (single) и совместный (joint).Одиночный заказ - ничего особенного, строка в БД с колонками ID, заказчик, стоимость, статус и т. д.Совместный заказ - заказ, который делают несколько клиентов, они объединяются в так называемые "группы" - там у них есть чат, там они видят с кем они заказывают еду, видят статус заказа, цену и т. д. Совместные заказы также суются в таблицу orders с пометкой "совместный"
Сайт работает только через rest API. Схема заказа такая:POST запрос на /orders для создания заказа. Юзер передает товары которые хочет заказать и тип заказа - single или joint.Сервер сует заказ в таблицу orders и возвращает 201.Юзер начинает делать периодические запросы на GET /orders/current для обновления инфы о заказе
Все понятно с одиночным - строка в БД с заказом и все. А с совместными все сложнее - там несколько пользователей. Допустим, 3 пользователя объединены в одну группу. Получается, что в таблице orders три одинаковых строки (только ID создателя отличаются). Вдруг статус заказа поменялся - и мне нужно сейчас у этих 3 строк статус обновить? Как-то некрасиво получается.
У меня есть решение этой проблемы - создать вообще другую сущность Group которая никак не пересекается с Order. Или есть более адекватное решение?
Надеюсь, вы поняли мой вопрос) Пишите, если что-то непонятно в тексте вопроса)
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Да, ваш вопрос понятен. Проблема с повторяющимися строками в таблице orders при совместных заказах действительно может усложнить процесс обновления данных.
Создание отдельной сущности Group, которая будет содержать информацию о группе пользователей, объединенных для осуществления совместного заказа, может быть хорошим решением данной проблемы. В этом случае таблица orders будет содержать только информацию о заказах, а связь между заказами и пользователями из группы будет осуществляться через таблицу Group.
Когда происходит изменение статуса заказа, вам будет достаточно обновить информацию только в одной строке таблицы orders, а затем в таблице Group связать этот заказ с соответствующей группой пользователей.
Таким образом, вы избежите дублирования данных и упростите обновление информации о заказах в случае совместных заказов.