Форматы данных «один к одному» и «один ко многим» в ArangoDB

Новичок в графовом моделировании и ArangoDB, я пытаюсь заменить реляционную базу данных. Для отношений «один к одному» или «один ко многим» я изо всех сил пытаюсь найти правильный способ структурировать свои документы и ребра.

UML-представление базы данных

Например, заменить таблицы auth_credentials, auth_fb, auth_google, содержащие информацию, позволяющую пользователям авторизоваться в различных сервисах (логин-пароль, facebook, google). Я могу представить 3 способа структурирования данных:

  • Создайте коллекции auth_* с данными аутентификации и edgeCollections auths_users, чтобы связать их с пользователями. Это хорошо соответствует приведенной выше схеме, но я считаю громоздким создание 1 документа и 1 ребра для каждого объекта аутентификации.
  • В моих users документах есть атрибут auths, который содержит массивы объектов с аутентификационной информацией. Я ожидаю, что будет сложно запрашивать пользователей на основе некоторой аутентификационной информации, и это, вероятно, упускает из виду график.
  • Создайте edgeCollections auth_*, где _from и _to связаны с дескриптором пользователя, которому принадлежит информация для проверки подлинности.

Мне больше нравится последний вариант, но я боюсь, что использование edgeCollections там, где у нас всегда _from == _to, является антипаттерном. Точно так же для groups я бы сделал их краями от и к их администратору.

Подводя итог: для представления данных B, принадлежащих данным A, является ли хорошим подходом создание ребра (от A до A), содержащего данные B?


database database-design arangodb
person Elzéar    schedule 14.05.2018    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

{
    "_id": "user/1234",
    "auth": {
        "credentials": { ... },
        "facebook": { ... },
        "google": { ... }
    }
}

Вложенные атрибуты являются необязательными, например. если нет никаких данных для аутентификации Google, просто оставьте атрибут "google" пропущенным.

Пути к атрибутам очень легко доступны, например. auth.credentials. Вы также можете создать индексы для вложенных атрибутов, если это необходимо. С массивами в этом отношении есть некоторые ограничения, и немного сложнее получить определенную информацию об аутентификации из массива (если вы не определяете фиксированный порядок, то есть учетные данные в индексе массива 0 и т. д., но ваша структура данных не будет больше не быть самоописательным).

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

person CodeManX    schedule 15.05.2018