#graph #neo4j #graph-databases #amazon-neptune
#График #neo4j #график-базы данных #amazon-нептун
Вопрос:
Я пытаюсь смоделировать доступ к учетной записи в graph DB.
Учетная запись может иметь несколько пользователей и несколько функций. Пользователь может иметь доступ ко многим учетным записям. Каждая учетная запись может предоставлять доступ только к части функций для каждого пользователя.
Один из способов, которым я вижу это, — представлять доступ для каждого пользователя через атрибуты отношений, это позволяет иметь общий функциональный узел.
пользователь_1 имеет доступ к account_1-feature_1 и account_2-feature-2. пользователь_1 не имеет доступа к account_1-feature_2, даже если он включен для учетной записи.
Другой способ моделирования того же доступа, но без атрибута отношения, — создать узлы функций, специфичные для учетной записи.
Вопрос 1. какой из этих 2 способов является более «правильным» моделированием в мире graph DB?
Теперь, чтобы сделать вещи более интересными, учетная запись также может иметь части, к которым могут быть доступны несколько учетных записей, и определенная функция должна быть ограничена, чтобы быть доступной только для определенной части пользователем.
В этом примере пользователь_1 может получить доступ к account_1 только для part_a feature_1.
Мне кажется, что определение атрибута для отношения — это путь к возможности ограничить доступ пользователей по функциям и по части учетной записи. Однако, читая neo4j powerpoints, это было бы одним из запахов кода отношений, имеющих «множество свойств, подобных атрибутам». Есть ли лучший способ решить такую проблему на графике?
Комментарии:
1. В зависимости от масштаба вашей базы данных я бы предпочел первое. Кроме того, поддерживать второй подход сложнее, потому что вам придется создавать / изменять узел featureX_accountY каждый раз, когда вы вносите изменения в учетную запись или функции или и то, и другое. Только мои 2 цента.
Ответ №1:
Я могу ошибаться здесь, но вот мои мысли. Вариант 1 определенно звучит лучше с точки зрения моделирования, однако я не понимаю, как вы можете поддерживать согласованность данных, не создавая для этого тяжелой техники. Например, если кто-то удаляет Account1.Feature1 и не обновляет ребро из User1 -> Account1, тогда у вас в конечном итоге будут устаревшие правила RBAC в системе. Вы думаете, что у вас есть доступ к чему-то, но на самом деле эта «вещь» больше не существует. Вариант 2 может показаться не очень привлекательным с точки зрения модели данных, но он обеспечивает согласованность ваших данных. Если вы удалите Account1.Особенность 1, край автоматически удаляется в той же транзакции.
Единственным недостатком является то, что вам нужно понести дополнительные расходы при вставке, когда вам нужно вставить намного больше узлов, чем вариант 1. Для системы RBAC я считаю, что это справедливый компромисс.
Тот же комментарий относится и ко второй половине вашего вопроса.