MongoDB Schema Design

Da MongoDB blev introduceret for et par år siden, var en af ​​de vigtige funktioner, der blev fremhævet, evnen til at være "skemaløs" – hvad betyder det for dine dokumenter?

MongoDB-skemadesign håndhæver ikke noget skema på de dokumenter, der er gemt i en samling. MongoDB gemmer i det væsentlige JSON-dokumenter, og hvert dokument kan indeholde enhver struktur, du ønsker. Overvej nogle eksempler fra vores "kontaktpersoner"-samling nedenfor. Her er et dokument, som du kan gemme:

{
  'name':'user1',
  'address':' 1 mountain view',
  'phone': '123-324-3308',
  'SSN':'123-45-7891'
}

Nu kan det andet dokument, der er gemt i samlingen, have dette format:

{
  'name': ' user2',
  'employeeid': 546789
}

Det er ret fedt, at du kan gemme begge disse dokumenter i samme samling. Problemet starter dog, når du skal hente disse dokumenter fra samlingen. Hvordan kan du se, om det hentede dokument indeholder format 1 eller format 2? Du kan kontrollere, om det hentede dokument indeholder 'ssn'-feltet og derefter træffe en beslutning. En anden mulighed er at gemme dokumenttypen i selve dokumentet:

{
  'type': xxx,
  'name': ....
  ...
}

I begge disse tilfælde er det, du har opnået, at flytte skemahåndhævelsen fra databasen til applikationen -

Der er altid et skema, det er bare et spørgsmål om, hvor det er implementeret.

Hvis du har de rigtige indekser, afhjælper det problemet til en vis grad. Hvis et flertal af dine forespørgsler er af 'medarbejder' ved du, at det hentede dokument altid er af det andet format - dog vil resten af ​​din kode, der ikke bruger dette indeks, stadig have det ovenfor nævnte problem. Hvis du også bruger en ODM som mongoose, håndhæver den automatisk allerede et skema for dig oven på MongoDB.

Der er flere applikationer, der drager fordel af denne fleksibilitet. Et scenarie, der kommer til at tænke på, er tilfældet med et skema, hvor der er en række valgfrie felter/kolonner. I MongoDB er der ingen straf for at have nogle manglende kolonner. Hvert dokument kan kun indeholde de felter, det har brug for.

Dokumentvalidering

Fra version 3.2.x understøtter MongoDB nu konceptet med skemavalidering ved hjælp af "validator"-konstruktionen. Dette giver mange niveauer af validering - så du kan vælge det niveau, der fungerer for dig. Standardadfærden, hvis du ikke bruger validator, er den tidligere skemaløse adfærd. Typisk vil du oprette "validatorerne" på tidspunktet for oprettelse af samlingen

db.createCollection( "contacts",
   { validator: { $or:
      [
         { employeeid: { $exists: true }},
         { SSN: { $exists: true } }
      ]
   }
} )

Eksisterende samlinger

Eksisterende samlinger kan opdateres ved hjælp af 'collMod'-kommandoen:

db.runCommand( {
  collMod: "contacts”,
  validator: { $or: [ { employeeid: { $exists: true }}, { SSN: { $exists:true} } ] }
} )

Valideringsniveau

MongoDB understøtter konceptet 'ValidationLevel'. Standard valideringsniveauet er 'streng', hvilket betyder, at indsættelser og opdateringer mislykkes, hvis dokumentet ikke opfylder valideringskriterierne. Hvis valideringsniveauet er 'Moderat', anvender det valideringen på eksisterende dokumenter, der opfylder valideringskriterierne. Dokumenter, der eksisterer i øjeblikket og ikke opfylder kriterierne, valideres ikke. Selv om det er praktisk, kan valideringsniveauet 'Moderat' få dig i problemer senere hen - så det skal bruges med omhu.

Valideringshandling

Som standard er valideringshandlingen 'Fejl'. Hvis dit dokument ikke valideres, er det en fejl, og opdateringen/indsættelsen mislykkes. Du kan dog også indstille valideringshandlingen til at 'advare', som grundlæggende logger skemaovertrædelsen i loggen , men fejler ikke indsættelsen.

Hvilke skemadesigneksempler der vil hjælpe dig med dit næste projekt, så fortæl os det!