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

Коллеги, задумался над такой проблемой: как сделать разный статус заказа в один момент времени для разных пользователей?

Задача может стоять так: а) заказ передаётся по цепочке пользователей, где на каждом этапе с ним что-то происходит. Пользователь П1 создаёт Заказ, он получает статус А. Потом отправляет его пользователю П2, Заказ меняет статус на А1. Пользователь П2 выполняет действие над заявкой, статус меняется на Б1 и она переходит далее по цепочке. Для предыдущего пользователя П1 статус остаётся неизменным - А1. Пользователь П3 получает заявку и видит её со уже статусом В1.

б) задачу можно упростить, выкинув передачу по цепочке, оставив лишь суть: в один момент времени N пользователей должны видеть "свой" статус. Наверное, так поставить задачу даже правильней, потому как реализацию цепочки можно рассматривать как отдельную задачу.

Логично предположить, что изначально должен существовать некий реестр возможных статусов:

table status 
N | key
-----------------
1 | draft
2 | new
3 | processing
N | ....

Второе. Нужно определится с количество разных пользователей ("ролей"), для которых могут быть разные статусы. Ну, предположим, их трое: Трус, Балбес и Бывалый.

Тут пути расходятся. Нужно определится, в какой логике работают статусы. Если развитие событий происходит линейно, можно запилить подобную таблицу:

N | key        | Trus        | Balbes      | Byvaly      |             
-----------------------------------------------------------
1 | draft      | Черновик    | Черновик    | Неизвестный |
2 | new        | Новый       | Черновик    | Неизвестный |
3 | processing | Обработка   | Обработка   | Неизвестный |
4 | finish     | Готово      | Обработка   | Неизвестный |
N | ....       |             |             |             |

Где каждый статус должен иметь текстовое обозначение для каждой роли. Тем самым, каждый видит своё имя статуса, в зависимости от роли/пользователя.

Но это не интересно. Ведь события могут проистекать нелинейно. И вот тут я забуксовал. Единственное решение, которое приходит в голову, это иметь собственную матрицу статусов заказа на каждую роль пользователя.

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

Ещё одно следствие такой логики — как, скажем, сделать выборку из БД всех новых заказов всех пользователей, если у каждого свой набор статусов (и идентификаторов соответственно). Нет, сделать то можно... но будет ли это решение красивым?

Словом, вопросов стало много. Интересно услышать тех, кто сталкивался или имеет представление как решаются задачи подобного типа.

Дополняю вопрос:

Нас интересует нелинейная обработка заказа:

Итак.

1) Есть пользователи (П1, П2, П3), каждый пользователь имеет определённую роль. Для упрощения, указывая пользователя буем подразумевать, что все они в разных ролях.

2) Представим жизненный цикл заявки:

• П1 создаёт заявку, она направляется П2;
• П2 над ней выполняет действия и тем самым изменяет её статус;
• П2 возвращает заявку П1 или её П3;

(Пока заявка от П1 находится у П2/П3 он видит один единственный статус "на боработке", в то время как отношения П2 и П3 регламентируются своими собственными статусами, но П1 это не должно парить)

Тут вилка: - заявку получил (вернулась обратно) П1; - заявку получил П3

Логика остаётся та же самая. Пользователь колдует над заявкой и отправляет её взад или дальше по цепочке. Т.е. не существует строгой последовательности обработки заказа в том смысле, что она должна "не сворачивая с пути" пройти от П1 к П3. Указанная вилка может повторится вновь N раз между П1 и П2, и между П2 и П3.

Иными словами последовательность обработки выглядит след. образом:

П1 ←→ П2 ←→ П3

Пока я тут вижу два реестра статусов:

• П2 и П3 (это классический случай)
• для П1

а может и и для каждой роли отдельно.

Почему два реестра статусов? Потому, что бизнес-логика для каждой роли пользователя может быть разной. П1 может работать в пределах, допустим, четырёх статусов (новая, обработка, отказано, подтверждено), тогда как в отношениях П2 и П3 статусами может быть отражена более детальная картина происходящих процессов.

Но несколько реестров повлечёт за собой геморой в реализации. Как компромисс вижу возможность хранить доступные статусы для каждой роли на базе одного реестра. Т.е. имеем таблицу со всеми возможными статусами (выше, рис. 1), и имеем пивотную таблицу для каждой роли с доступными только ему статусами (ну или колонок в таблицу заказа добавить - это уже второстепенный вопрос).

Что имеем в итоге: заказ должен хранить собственных индекса статуса для пользователя (т.е. роли ). Но все статусы, как я заметил в предыдущем абзаце, будут из единого реестра, снимая тем самым гемор в реализации.

Т.е. на выходе имеем что-то типа этого:

id | order_id   | role1       | Role2       | role3       |             
-----------------------------------------------------------
1  | 1          | 1           | 2           | 3           |