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

Пристегнитесь, это сложный вопрос.

У нас есть система, которая работает с большими наборами данных. (от миллиона до миллиарда записей на большую таблицу). Все данные обрабатываются в древовидной структуре узлов.

Мы используем Symfony2 и систему безопасности Symfony2 (объекты домена, Acls, Aces и т. Д.). Наше дерево Acl отражает наше дерево узлов.

Чтобы придумать какой-то язык:

• DP Определенное разрешение, т. Е. Запись ace на этом узле acl
• EP Действующее разрешение, без записи ace, разрешение, унаследованное от родителя с DP

С точки зрения бизнес-логики, мы назначаем объекту 0 или 1 ace для каждого пользователя и полагаемся на наследование там, где его нет. Корень> lvl1 (DP: VIEW)> lvl2> lvl3 (EP: VIEW)

Пока все хорошо. Все это работает.

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

Leaf < Parent < GrandParent < Root
Leaf < AssociatedNode < AssociatedNodeParent < AssociatedNodeGrandParent < Root
 ...

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

• Множественное родительское поведение в дереве acl
  • Плюсы
    • Кажется чище?
  • Минусы
    • Практически полностью переработана система безопасности, чтобы добавить это.
    • Возможное крысиное гнездо.
• Повторяющиеся идентификаторы / ACL объектов для сущностей с указанием разных родителей.
  • Плюсы
    • Э ...
  • Минусы
    • Возможно создание очень большого количества ACL-записей.
    • Трудно управлять кодом.