マルチタイプのユーザー向けのマングースモデル

このアプローチを使用することをお勧めします。

別のSchemasが必要です Accountの場合、Teacher およびStudent したがって、教師と生徒の間の異なる情報を1か所に混在させないでください。

アカウント

var Account = new Schema({
    email:String,
    password:String,
    _teacher:{type:Schema.Types.ObjectId, ref:'Teacher'},
    _student:{type:Schema.Types.ObjectId, ref:'Student'}
})

アカウントでは、教師アカウントが生徒モデルを参照している場合は、教師モデルを参照する必要があります。

Accountかどうかを確認するには TeacherですまたはStudent _teacherを確認するだけです、値がある場合は、Teacher アカウントそれ以外の場合は学生です。ただし、条件をより一意にするために、両方の_teacherを確認してくださいおよび_student 。

このアプローチにより、教師も学生になることを許可する場合（これは不可能ではありません）、将来的に多くのリファクタリングを節約できます。教師は同じアカウントを使用して学生として登録できます。 Googleが行っているのと同じように、アカウント/メールで複数の種類のアプリを使用します。

先生

var Teacher = new Schema({
    name:{type:Schema.Types.ObjectId, ref:'Name'}
    // Other teachers info
})

学生

var Student = new Schema({
    name:{type:Schema.Types.ObjectId, ref:'Name'}
    // Other students info
})

名前

この部分では、名前に別のモデルが必要な理由を疑問に思っているかもしれません。これは、このアプローチでは1つのrouteを使用できるためです。またはendpoint またはquery アプリ全体でユーザーを検索します。名前を検索すると、結果が一致するすべての生徒と教師が、2つの異なるコレクション（教師コレクションと生徒コレクション）を調べずにクエリされます。

これの良い使用例は、すべての生徒と教師を管理できる管理ダッシュボードがあることです。そのダッシュボードでは、教師と生徒の両方に対して1つの検索フィールドしか使用できません。

var Name = new Schema({
    firstName:String,
    middleName:String,
    lastName:String
})

良い読み物

その他のヒント

Addressを区切ることもできますここの名前でやったように。理由？ Nameと同じ目的、場所による検索機能などを追加することをお勧めします。

これがお役に立てば幸いです。