Конструкция схемы MongoDB для нескольких учетных записей пользователей auth

Я собираюсь создать мое приложение node.js/express/ mongoose/ паспорт, и я думаю о правильном дизайне схемы для пользователей и учетных записей.

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

Я не могу придумать хорошего решения для этой ситуации. Вот варианты, о которых я думаю:

1. Наличие модели профиля и моделей учетных записей. Профильные документы представляют собой уникального пользователя, в то время как учетная запись предоставляет имя пользователя и пароль (внутренняя учетная запись) или данные аутентификации у аут-провайдера (внешняя учетная запись). Профиль должен иметь хотя бы один вложенный документ учетной записи.

var ExtAccountSchema = new Schema({
    type: String, // eg. twitter, facebook, native
    uid: String
});

var IntAccountSchema = new Schema({
    username: String,
    password: String
});

var ProfileSchema = new Schema({
    firstname: String,
    lastname: String,
    email: String,
    accounts: [Account] // Pushing all the accounts in there
});

То, что мне не нравится в этом, - это не столь согласованные документы учетной записи, полученные из разных данных учетной записи, и тот факт, что мне сложно найти нужную учетную запись, когда мой пользователь входит в систему (поиск uids и типов учетных записей во вложенных документах -.- )

2. Имея все данные в одной модели

var ProfileSchema = new Schema({
    firstname: String,
    lastname: String,
    email: String,        
    twitter-uid: String,
    facebook-uid: String
    password: String
});

Хорошо, это просто уродливо. - Возможно, было бы проще/быстрее найти правильные данные учетной записи, но это нехорошо поддерживать.

Есть ли лучшее решение? Есть ли наилучшая практика?

Ответ 1

1) Существуют три стратегии, которые вы можете использовать для структурирования своих данных в MongoDB:

a) Массив встроенных документов
b) Массив встроенных ссылок
c) Развернуто в родительский документ

Стратегия (a) - это первая, которую вы описываете, где документ профиля содержит массив поддоменов Account.

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

Стратегия (c) - это та, которую вы описываете как "имеющую все данные в одной модели".

2) Обычно считается, что Best Practice использует массив встроенных документов, особенно если информация в них может различаться. Если это упростит вашу жизнь, вы можете использовать ключ, чтобы различать тип учетной записи, например:

  { 
    firstname: 'Fred',
    lastname: 'Rogers',
    email: '[email protected]',

    accounts: [
             { kind: 'facebook',
               uid: 'fred.rogers'
             },
             { kind: 'internal',
               username: 'frogers',
               password: '5d41402abc4b2a76b9719d911017c592'
             },
             { kind: 'twitter',
               uid: 'fredr'
             }
          ]
    }

3) MongoDB позволяет выполнять поиск по встроенному документу. Поэтому вы должны написать следующий запрос (синтаксис JavaScript):

 db.profile.find( 
        { email: '[email protected]', 'accounts.kind': 'facebook' }
        );

С соответствующими индексами этот запрос будет довольно быстрым.