Конструкция схемы 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' }
);
С соответствующими индексами этот запрос будет довольно быстрым.