다중 인증 사용자 계정을 위한 MongoDB 스키마 설계

다중 인증 사용자 계정을 위한 MongoDB 스키마 설계

node.js/express/mongoose/passport 애플리케이션을 구축하려고 하는데 사용자와 계정에 적합한 스키마 설계를 생각하고 있습니다.

네이티브 계정뿐만 아니라 트위터와 페이스북에서도 로그인하는 사용자가 있을 것입니다.이후 단계에서는 사용자가 트위터와 페이스북을 모두 내 애플리케이션(그리고 어쩌면 더 많은 외부 계정)과 연결하기를 원합니다.

저는 그 상황에 대한 좋은 해결책이 떠오르지 않습니다.제가 생각하는 옵션은 다음과 같습니다.

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
});

제가 싫어하는 것은 계정 데이터가 다르기 때문에 계정 문서가 일치하지 않는 점과 사용자가 로그인할 때 올바른 계정을 찾는 데 어려움이 있다는 점입니다(내스트된 문서에서 udid와 계정 유형 검색 -.).

2. 모든 데이터를 단일 모델로 보유

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

이것은 보기 흉할 뿐입니다. 올바른 계정 데이터를 찾는 것이 더 쉽고 빠를 수 있지만 유지 관리하기에는 좋지 않습니다.

더 좋은 해결책이 있습니까?모범 사례가 있습니까?

MongoDB에서 데이터를 구성하기 위해 취할 수 있는 세 가지 전략이 있습니다.

• 포함된 문서 배열
• 포함된 참조 배열
• 상위 문서로 확장됨

전략(a)은 프로파일 문서에 계정 하위 문서의 배열이 포함된 첫 번째 전략입니다.

전략(b)는 전략(a)과 유사하지만 실제 문서를 포함하는 대신 다른 문서(일반적으로 계정 모음)에 대한 참조 배열을 사용합니다.

전략(c)은 "모든 데이터를 하나의 모형에 포함"하는 전략입니다.

일반적으로 내장된 문서의 배열을 사용하는 것이 가장 좋은 방법으로 간주됩니다. 특히 문서의 정보가 다를 수 있는 경우에는 더욱 그렇습니다.키를 사용하여 다음과 같이 계정 유형을 구분할 수 있습니다.

  { 
    firstname: 'Fred',
    lastname: 'Rogers',
    email: 'fred.rogers@example.com',

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

MongoDB를 사용하면 내장된 문서를 검색할 수 있습니다.따라서 다음 쿼리(자바스크립트 구문)를 작성합니다.

 db.profile.find( 
        { email: 'fred.rogers@example.com', 'accounts.kind': 'facebook' }
        );

적절한 인덱스를 사용하면 이 쿼리는 상당히 빨라집니다.

당신과 비슷한 욕구를 가진 사람에게 도움이 되었으면 합니다.

MongoDB의 스키마 설계 및 데이터 모델링

• SQL에는 고정/엄격 스키마가 있는 반면 NoSQL에는 동적/유연한 스키마가 있습니다. 즉, 문서 구조를 적용하지 않습니다.

• MongoDB에는 두 가지 유형의 데이터 모델이 있습니다.

  • 임베디드 데이터 모델링:
    • 단일 문서 구조를 가지며 비정규화된 모델이라고 합니다.
    • 문서 수준 원자성 작업을 지원합니다.
    • CRUD 수행이 용이함
    • 사례의 70%를 사용하며 읽기 작업에 대해 높은 성능을 발휘합니다.
    • 크기는 16MB의 임계값에 쉽게 도달할 수 있으며 중복성이 높습니다.
    • 일대일 및 일대일 관계에서 권장되는
  • 참조 또는 연결된 데이터 모델링:
    • SQL 데이터베이스의 정규화된 테이블을 모방하여 데이터 중복 및 중복성을 줄입니다.
    • reference 또는 _id는 기본 키와 외부 키를 사용하여 SQL에서 테이블을 조인하는 것과 유사한 다른 문서를 참조하는 데 사용됩니다.
    • 사례의 30%에 사용됩니다.
    • 다대다 관계에서 권장되는

데이터 모델링의 관점

• 개념적 데이터 모델링: 기능 및 서비스에 대한 큰 그림.
  • ER 데이터 모델링: 데이터베이스 설계에 대한 그래픽 접근 방식.
  • 스키마 설계
• 논리적 데이터 모델링:개념적 데이터 모델링은 프로그래밍 언어, 테이블 등을 사용하여 논리적 데이터 모델링(프로그램)으로 변환됩니다(서버 코드)
• 물리적 데이터 모델링: 사용자가 실제 데이터를 삽입하는 논리적 DM을 실행합니다. (데이터베이스)

데이터 모델 유형

• 평면, 별, 계층, 관계형, 객체-관계형

문서 간의 모델 관계

• 일반적으로 응용프로그램이 한 번의 읽기 작업으로 필요한 모든 정보를 수신하도록 스키마를 구성해야 합니다.

임베디드 문서를 사용한 모델 일대일 관계

  - In referenced or normalized data model, If one document is frequetly refering some data in another document, It would create better data model to embed both documents into one.
  - If a single document seems to be large, it is better split your data into referential model, the most frequently-accessed portion of the data should go in the collection that the application loads first
  ```json
  // one person and one address
  {
     _id: "joe",
     name: "Joe Bookreader",
     address: {
              street: "123 Fake Street",
              city: "Faketon",
              state: "MA",
              zip: "12345"
              }
  }
  ```

포함된 문서를 사용한 모델 일대일 관계

• 그것을 위한 모델을 설계한다는 점에서도 일대일로와 같은 개념을 기반으로 합니다.

// one person and his multiple address
{
   "_id": "joe",
   "name": "Joe Bookreader",
   "addresses": [
               {
                  "street": "123 Fake Street",
                  "city": "Faketon",
                  "state": "MA",
                  "zip": "12345"
               },
               {
                  "street": "1 Some Other Street",
                  "city": "Boston",
                  "state": "MA",
                  "zip": "12345"
               }
            ]
}

참조 문서를 사용한 모델 일대일 관계

• 어떤 경우에는 아래와 같이 더 나은 성능을 위해 참조 모델을 사용하는 것이 좋습니다.
• 게시자 데이터가 반복되지 않도록 하려면 참조를 사용하고 게시자 정보를 책 모음과 별도의 모음에 보관합니다.

   {
   _id: 'some string'
   name: "O'Reilly Media",
   founded: 1980,
   location: "CA",

   books: [123456789, 234567890, ...]

   }

   {
      _id: 123456789,
      title: "MongoDB: The Definitive Guide",
      author: [ "Kristina Chodorow", "Mike Dirolf" ],
      published_date: ISODate("2010-09-24"),
      pages: 216,
      language: "English"
   }

   {
      _id: 234567890,
      title: "50 Tips and Tricks for MongoDB Developer",
      author: "Kristina Chodorow",
      published_date: ISODate("2011-05-06"),
      pages: 68,
      language: "English"
   }

• 나중에 책 배열이 커질 가능성이 있는 경우, 출판사 참조를 책 문서 안에 저장하는 것이 좋습니다.
• 스키마의 지능적인 변화를 관찰하는 방법_id정보(즉, 게시자 ID)는 BOOK COLLECTION에서 다음과 같이 참조됩니다.publisher_id.

   {
   _id: "oreilly",
   name: "O'Reilly Media",
   founded: 1980,
   location: "CA"
   }

   {
      _id: 123456789,
      title: "MongoDB: The Definitive Guide",
      author: [ "Kristina Chodorow", "Mike Dirolf" ],
      published_date: ISODate("2010-09-24"),
      pages: 216,
      language: "English",

      publisher_id: "oreilly"

   }

   {
      _id: 234567890,
      title: "50 Tips and Tricks for MongoDB Developer",
      author: "Kristina Chodorow",
      published_date: ISODate("2011-05-06"),
      pages: 68,
      language: "English",

      publisher_id: "oreilly"

   }

언급URL : https://stackoverflow.com/questions/11101955/mongodb-schema-design-for-multiple-auth-user-accounts