Doctrine — структура БД для хранения документов, и участников документооборота?
Задача не сложная. Но вы сами себя запутали. Методик вы не найдёте. Вам надо научиться анализировать происходящий у вас бизнес-процесс и разделять его на алгоритм и контекст. Решать эту задачу за вас было бы неправильно, поэтому вот вам советы:
1. Выкиньте из документа все признаки, отвечающие за согласование.
2. Введите новую сущность Согласование.
3. Свяжите Документ с сущностью Согласование единственной ссылкой. Так вы очистите документ от ненужной ему информации. Ссылка должна храниться на стороне Согласования (Owning Side Relation), но на стороне Документа должна быть возможность получить сущность Согласования (Inverse Side Relation).
4. Если я правильно понял, то ваш документ может быть согласован по трём разным алгоритмам. Если это так, то воспользуйтесь возможностью доктрины Class Table Inheritance. Вы получите одну связь со стороны документа, но разные алгоритмы аппрува со стороны Согласования.
5. В каждом из Согласований реализуйте метод isApproved со своей логикой.
6. После такого разделения вы сможете строить алгоритмы, привязываясь к каждому типу Согласований по отдельности, не обращая внимание на другие.
Приветствую! Мне в течение последнего года доводилось делать три похожих проекта документооборота. Хотелось бы поделиться со своим решением, как я организовал структуру таблиц (они же и сущности в доктрин).Первое:
У моих проектов было несколько маршрутов согласования. Поэтому я хранил их отдельно. И называл их workflow (бизнес процесс)Workflow: (Маршрут согласования)
    id
    name (Название маршрута согласования)
WorkflowPoint: (Точка согласования)
    id
    title (Название точки. Например "Согласование фин директора")
    workflow_id (Связанный маршрут)
    user_id (Пользователь, который рассматривает документ в этой точке согласования)
    order_id (Порядковый номер точки в маршруте)
    roles (Права пользователя, в данной точке согласования)Второе:
В моих проектов в одном документе согласования могли храниться несколько файловых вложении. Поэтому Файл и Документ согласования хранились отдельно.Approval: (Документ согласования)
    id
    title (Название документа)
    author_id (Инициатор)
    state = 0 (Состояние документа. 0 - черновик. 1 - в процессе согласования. 2 - одобрено. 3 - отказано. 4 - архивировано)
    workflow_id (Маршрут, по которому движется данный документ. По умолчанию null, кроме того, когда состояние документа в процессе согласования)
    workflow_point_id (Текущая точка согласования в маршруте. При одобрении, указывается следующая точка)
    approval_user_id (Пользователь, который должен рассмотреть документ в текущий момент. Это поле чисто для удобства в поиске)
Attachment: (Файл-вложение)
    id
    approval_id (Связанный документ)
    file_path (Путь к файлу)
    author_id (Пользователь, который вложил файл)
Я значительно упростил структуру, чтобы просто дать Вам идею для размышления. В реальных проектах было гораздо сложнее