Моделирование учетной записи GraphDB: атрибут отношения доступа пользователя или отношение?

Question

Я пытаюсь смоделировать доступ к учетной записи в графической БД.

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

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

пользователь_1 имеет доступ к account_1-feature_1 и account_2-feature-2. У user_1 нет доступа к account_1-feature_2, даже если он включен для учетной записи.

Еще один способ смоделировать тот же доступ, но без атрибута взаимосвязи, - создать узлы специфичных для учетной записи узлов.

Вопрос 1: какой из этих двух способов является более «правильным» моделированием в мире графовых БД?

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

В этом примере user_1 может получить доступ к account_1 только для part_a feature_1.

Мне кажется, что определение атрибута для отношений - это способ, с помощью которого можно ограничить доступ пользователей по функциям и по части учетной записи. Тем не менее, чтение neo4j powerpoints было бы одним из запахов кода отношений, имеющих «много атрибутоподобных свойств». Есть ли лучший способ подойти к такой проблеме в графе?

Answer 1

Я могу ошибаться, но вот мои мысли.Вариант 1 определенно звучит лучше с точки зрения моделирования, однако я не понимаю, как можно поддерживать согласованность данных, не создавая для этого тяжелую технику.Например, если кто-то удаляет Account1.Feature1 и не обновляет ребро из User1 -> Account1, то в конечном итоге вы получите устаревшие правила RBAC в системе.Вы думаете, что имеете доступ к чему-то, но на самом деле эта «вещь» больше не существует.Вариант 2 может показаться не очень привлекательным с точки зрения модели данных, но он сохраняет ваши данные согласованными.Если вы удалите Account1.Feature1, ребро автоматически удаляется в той же транзакции.

Единственным недостатком является то, что вам нужно нести дополнительные расходы при вставке, когда вам нужно вставить гораздо больше узлов, чем в варианте 1. Для системы RBAC, я думаю, это справедливый компромисс.

Этот же комментарий относится и ко второй половине вашего вопроса.