MongoDB Schema Design

När MongoDB introducerades för några år sedan var en av de viktiga funktionerna som framhölls möjligheten att vara "schemalös" – vad betyder detta för dina dokument?

MongoDB-schemadesign tvingar inte fram något schema på dokument som lagras i en samling. MongoDB lagrar i huvudsak JSON-dokument, och varje dokument kan innehålla vilken struktur du vill. Betrakta några exempel från vår "kontakter"-samling nedan. Här är ett dokument som du kan lagra:

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

Nu kan det andra dokumentet som lagras i samlingen ha detta format:

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

Det är ganska coolt att du kan lagra båda dessa dokument i samma samling. Problemet börjar dock när du behöver hämta dessa dokument från samlingen. Hur vet man om det hämtade dokumentet innehåller format 1 eller format 2? Du kan kontrollera om det hämtade dokumentet innehåller fältet 'ssn' och sedan fatta ett beslut. Ett annat alternativ är att lagra dokumenttypen i själva dokumentet:

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

I båda dessa fall är det du har åstadkommit att flytta schematillämpningen från databasen till applikationen -

Det finns alltid ett schema, det är bara en fråga om var det implementeras.

Om du har rätt index lindrar det problemet till viss del. Om en majoritet av dina frågor är av "anställd" vet du att det hämtade dokumentet alltid är av det andra formatet - men resten av din kod som inte använder detta index kommer fortfarande att ha problemet som nämns ovan. Om du använder en ODM som mongoose, så tillämpar den automatiskt redan ett schema för dig ovanpå MongoDB.

Det finns flera applikationer som drar nytta av denna flexibilitet. Ett scenario som kommer att tänka på är fallet med ett schema där det finns ett antal valfria fält/kolumner. I MongoDB finns det ingen påföljd för att ha några saknade kolumner. Varje dokument kan bara innehålla de fält som behövs.

Dokumentvalidering

Från och med version 3.2.x MongoDB stöder nu konceptet med schemavalidering med "validator"-konstruktionen. Detta ger många nivåer av validering – så att du kan välja den nivå som fungerar för dig. Standardbeteendet om du inte använder validator är det tidigare schemalösa beteendet. Vanligtvis kommer du att skapa "validatorerna" när samlingen skapas

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

Befintliga samlingar

Befintliga samlingar kan uppdateras med kommandot 'collMod':

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

Verifieringsnivå

MongoDB stöder konceptet "ValidationLevel". Standardvalideringsnivån är "strikt" vilket innebär att infogningar och uppdateringar misslyckas om dokumentet inte uppfyller valideringskriterierna. Om valideringsnivån är "Moderat" tillämpas valideringen på befintliga dokument som uppfyller valideringskriterierna. Dokument som finns för närvarande och som inte uppfyller kriterierna valideras inte. Även om det är bekvämt kan valideringsnivån "Moderat" få dig i problem längre fram - så den måste användas med försiktighet.

Verifieringsåtgärd

Som standard är valideringsåtgärden "Fel". Om ditt dokument misslyckas med valideringen är det ett fel och uppdateringen/infogningen misslyckas. Du kan dock också ställa in valideringsåtgärden till "varna" som i princip loggar schemaöverträdelsen i loggen, men misslyckas inte med infogningen.

Vilka schemadesignexempel skulle hjälpa dig i ditt nästa projekt, låt oss veta!