Форматы данных один-к-одному и один-ко-многим в ArangoDB - PullRequest
Новая
       11

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

0 голосов
/ 15 мая 2018

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

UML representation of database

Например, чтобы заменитьтаблицы 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?

1 Ответ

0 голосов
/ 15 мая 2018

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

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

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

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

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

...