MongoDB Schema Design

Toen MongoDB een paar jaar geleden werd geïntroduceerd, was een van de belangrijke functies die werden aangeprezen de mogelijkheid om "schemaloos" te zijn. Wat betekent dit voor uw documenten?

MongoDB-schemaontwerp dwingt geen schema af op de documenten die in een verzameling zijn opgeslagen. MongoDB slaat in wezen JSON-documenten op en elk document kan elke gewenste structuur bevatten. Bekijk hieronder enkele voorbeelden uit onze verzameling 'contacten'. Hier is één document dat u kunt opslaan:

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

Nu kan het tweede document dat in de verzameling is opgeslagen van dit formaat zijn:

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

Het is best cool dat je beide documenten in dezelfde verzameling kunt opslaan. Het probleem begint echter wanneer u deze documenten uit de collectie moet halen. Hoe weet u of het opgehaalde document formaat 1 of formaat 2 heeft? U kunt controleren of het opgehaalde document het veld 'ssn' bevat en vervolgens een beslissing nemen. Een andere optie is om het type document in het document zelf op te slaan:

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

In beide gevallen heeft u de schemahandhaving van de database naar de toepassing verplaatst -

Er is altijd een schema, het is alleen de vraag waar het wordt geïmplementeerd.

Als je de juiste indexen hebt, wordt het probleem tot op zekere hoogte verholpen. Als de meerderheid van uw zoekopdrachten door 'employeeid' zijn, weet u dat het opgehaalde document altijd van het tweede formaat is - de rest van uw code die deze index niet gebruikt, heeft echter nog steeds het bovengenoemde probleem. Ook als je een ODM zoals mangoest gebruikt, dwingt het automatisch al een schema voor je af bovenop MongoDB.

Er zijn verschillende applicaties die profiteren van deze flexibiliteit. Een scenario dat in je opkomt is het geval van een schema met een aantal optionele velden/kolommen. In MongoDB is er geen straf voor het hebben van enkele ontbrekende kolommen. Elk document kan alleen de velden bevatten die het nodig heeft.

Documentvalidatie

Vanaf versie 3.2.x ondersteunt MongoDB nu het concept van schemavalidatie met behulp van de "validator"-constructie. Dit biedt veel validatieniveaus, zodat u het niveau kunt kiezen dat voor u werkt. Het standaardgedrag als u geen validator gebruikt, is het vorige schemaloze gedrag. Meestal maakt u de "validators" aan op het moment dat de collectie wordt gemaakt

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

Bestaande collecties

Bestaande collecties kunnen worden bijgewerkt met de opdracht 'collMod':

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

Validatieniveau

MongoDB ondersteunt het concept van 'ValidationLevel'. Het standaard validatieniveau is 'streng', wat betekent dat invoegingen en updates mislukken als het document niet aan de validatiecriteria voldoet. Als het validatieniveau 'Gemiddeld' is, wordt de validatie toegepast op bestaande documenten die voldoen aan de validatiecriteria. Documenten die momenteel bestaan ​​en niet aan de criteria voldoen, worden niet gevalideerd. Hoewel handig, kan het validatieniveau 'Gemiddeld' u in de loop van de tijd in de problemen brengen - dus het moet met zorg worden gebruikt.

Validatieactie

De validatieactie is standaard 'Fout'. Als uw document niet wordt gevalideerd, is dit een fout en mislukt het bijwerken/invoegen. U kunt de validatieactie echter ook instellen op 'waarschuwing', waarmee de schending van het schema in feite in het logboek wordt vastgelegd, maar de invoeging niet mislukt.

Welke voorbeelden van schemaontwerpen u kunnen helpen bij uw volgende project, laat het ons weten!