mangoestmodel voor meerdere soorten gebruikers

Ik stel voor om deze aanpak te gebruiken.

Je zou een apart Schemas moeten hebben voor Account , Teacher en Student dus de verschillende informatie tussen de docenten en studenten mag niet op één plek worden gemengd.

Account

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

Onder account moet u verwijzen naar het docentenmodel als het docentenaccount anders naar het studentenmodel verwijst.

Om te controleren of Account is Teacher of Student je zou gewoon _teacher . kunnen aanvinken , als het een waarde heeft, dan is het een Teacher account, anders is het een student. Maar om de voorwaarde voor jou unieker te maken, vink je beide _teacher . aan en _student .

Deze aanpak zal je in de toekomst veel refactoring besparen als je besluit om de leraar ook student te laten zijn (wat niet onmogelijk is), hij/zij kan gewoon hetzelfde account gebruiken en zich als student registreren. Net zoals wat Google doet, op account/e-mail meerdere soorten apps om te gebruiken.

Leraar

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

Leerling

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

Naam

Op dit onderdeel vraag je je misschien af waarom je een apart model voor naam nodig hebt. Nou, dat komt omdat je in deze benadering maar één route . kunt gebruiken of endpoint of query om gebruikers in uw app te zoeken. Als je op een naam zoekt, worden alle leerlingen en docenten met een overeenkomend resultaat bevraagd zonder in 2 verschillende collecties te kijken (lerarencollectie en leerlingencollectie).

Een goed gebruik hiervoor is dat je zeker een beheerdersdashboard hebt waar je alle studenten en docenten kunt beheren. In dat dashboard kun je maar één zoekveld vinden voor zowel docent als student.

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

Goed gelezen

Andere tips

U kunt ook het Address . scheiden zoals ik deed met de naam hier. Reden? Zelfde doel als bij de Name , wilt u misschien een functie voor zoeken op locatie of iets dergelijks toevoegen.

Ik hoop dat dit helpt.