стандартная ситуация. Есть заказчик , есть реквест на сервисы, есть круг лиц которые согласовывают доступ к сервисам.

для каждого сервиса прописан конкретный круг лиц согласователей. в базе согласователь делает тычку которая фиксируется в базе.

всё это в электронном виде на базе скуля.

каким образом спроектировать структуру таблиц чтобы реализовать процесс гуляния реквеста от одного согласователя к другому?

если к примеру 3 согласователя то реквест должен придти сначала к одному, потом к другому , а потом к третьему и мало того, реквест откатывается если первый в списке реквест запорол...

согласователь ставит "да" или "нет" и исходя из этой логики крутится бизнес-логика "полета" реквеста

есть что то подобное , чтобы свой педик не изобретать в этих ситуациях? парни ,подскажите !

замечания...

в один родительский реквест ( в котором фиксируется инфа от кого , откуда и etc) включается дочерние записи в которых идет контент по конкретному сервиса и именно мышиная возня согласования происходит по этим дочерним записям....


тыкните как оптимальней, надежней, я бы даже сказал проще ...