Как правильно спроектировать данную «махину»?

Делаю сайт доставки еды.

Клиенты делают заказ. Заказ может быть одиночный (single) и совместный (joint).

Одиночный заказ - ничего особенного, строка в БД с колонками ID, заказчик, стоимость, статус и т. д.

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

Сайт работает только через rest API. Схема заказа такая:

1. POST запрос на /orders для создания заказа. Юзер передает товары которые хочет заказать и тип заказа - single или joint.
   
2. Сервер сует заказ в таблицу orders и возвращает 201.
   
3. Юзер начинает делать периодические запросы на GET /orders/current для обновления инфы о заказе
   

Все понятно с одиночным - строка в БД с заказом и все. А с совместными все сложнее - там несколько пользователей. Допустим, 3 пользователя объединены в одну группу. Получается, что в таблице orders три одинаковых строки (только ID создателя отличаются). Вдруг статус заказа поменялся - и мне нужно сейчас у этих 3 строк статус обновить? Как-то некрасиво получается.

У меня есть решение этой проблемы - создать вообще другую сущность Group которая никак не пересекается с Order. Или есть более адекватное решение?

Надеюсь, вы поняли мой вопрос) Пишите, если что-то непонятно в тексте вопроса)