MongoDB-Schemadesign

Als MongoDB vor einigen Jahren eingeführt wurde, war eines der wichtigen Features, das angepriesen wurde, die Fähigkeit, „schemalos“ zu sein – was bedeutet das für Ihre Dokumente?

Das Schemadesign von MongoDB erzwingt kein Schema für die in einer Sammlung gespeicherten Dokumente. MongoDB speichert im Wesentlichen JSON-Dokumente, und jedes Dokument kann jede gewünschte Struktur enthalten. Sehen Sie sich unten einige Beispiele aus unserer „Kontakte“-Sammlung an. Hier ist ein Dokument, das Sie speichern können:

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

Jetzt kann das zweite in der Sammlung gespeicherte Dokument dieses Format haben:

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

Es ist ziemlich cool, dass Sie diese beiden Dokumente in derselben Sammlung speichern können. Das Problem beginnt jedoch, wenn Sie diese Dokumente aus der Sammlung abrufen müssen. Wie können Sie feststellen, ob das abgerufene Dokument Format 1 oder Format 2 enthält? Sie können überprüfen, ob das abgerufene Dokument das Feld „ssn“ enthält, und dann eine Entscheidung treffen. Eine andere Möglichkeit besteht darin, den Typ des Dokuments im Dokument selbst zu speichern:

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

In beiden Fällen haben Sie erreicht, dass die Schemadurchsetzung von der Datenbank in die Anwendung verschoben wurde -

Es gibt immer ein Schema, es ist nur eine Frage, wo es implementiert wird.

Wenn Sie die richtigen Indizes haben, wird das Problem bis zu einem gewissen Grad gemildert. Wenn ein Großteil Ihrer Abfragen nach „employeeid“ erfolgt, wissen Sie, dass das abgerufene Dokument immer das zweite Format hat – der Rest Ihres Codes, der diesen Index nicht verwendet, wird jedoch immer noch das oben erwähnte Problem haben. Auch wenn Sie ein ODM wie Mongoose verwenden, erzwingt es automatisch bereits ein Schema für Sie auf MongoDB.

Es gibt mehrere Anwendungen, die von dieser Flexibilität profitieren. Ein Szenario, das mir in den Sinn kommt, ist der Fall eines Schemas, in dem es eine Reihe optionaler Felder/Spalten gibt. In MongoDB gibt es keine Strafe für fehlende Spalten. Jedes Dokument kann nur die Felder enthalten, die es benötigt.

Dokumentvalidierung

Ab Version 3.2.x unterstützt MongoDB nun das Konzept der Schemavalidierung mit dem „validator“-Konstrukt. Dies bietet viele Validierungsstufen – Sie können also die Stufe auswählen, die für Sie am besten geeignet ist. Das Standardverhalten, wenn Sie den Validator nicht verwenden, ist das vorherige schemalose Verhalten. Normalerweise erstellen Sie die „Validatoren“ zum Zeitpunkt der Sammlungserstellung

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

Bestehende Sammlungen

Bestehende Sammlungen können mit dem Befehl „collMod“ aktualisiert werden:

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

Validierungsstufe

MongoDB unterstützt das Konzept von „ValidationLevel“. Die Standardvalidierungsebene ist „streng“, was bedeutet, dass Einfügungen und Aktualisierungen fehlschlagen, wenn das Dokument die Validierungskriterien nicht erfüllt. Wenn die Validierungsstufe „Moderat“ ist, wird die Validierung auf vorhandene Dokumente angewendet, die die Validierungskriterien erfüllen. Bereits vorhandene Dokumente, die die Kriterien nicht erfüllen, werden nicht validiert. Die Validierungsstufe „Moderat“ ist zwar praktisch, kann Sie jedoch später in Schwierigkeiten bringen – daher muss sie mit Vorsicht verwendet werden.

Validierungsaktion

Standardmäßig ist die Validierungsaktion „Fehler“. Wenn die Überprüfung Ihres Dokuments fehlschlägt, handelt es sich um einen Fehler, und das Aktualisieren/Einfügen schlägt fehl. Sie können die Validierungsaktion jedoch auch auf „Warnen“ setzen, wodurch die Schemaverletzung im Grunde genommen im Protokoll protokolliert wird, das Einfügen jedoch nicht fehlschlägt.

Welche Schemadesignbeispiele Ihnen bei Ihrem nächsten Projekt helfen würden, lassen Sie es uns wissen!