Progettazione di schemi MongoDB

Quando MongoDB è stato introdotto alcuni anni fa, una delle caratteristiche importanti propagandate era la capacità di essere "senza schemi". Cosa significa questo per i tuoi documenti?

La progettazione dello schema MongoDB non applica alcuno schema ai documenti archiviati in una raccolta. MongoDB archivia essenzialmente documenti JSON e ogni documento può contenere qualsiasi struttura desideri. Considera alcuni esempi dalla nostra raccolta "contatti" di seguito. Ecco un documento che puoi archiviare:

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

Ora il secondo documento archiviato nella collezione può essere di questo formato:

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

È piuttosto interessante che tu possa archiviare entrambi questi documenti nella stessa raccolta. Il problema, tuttavia, inizia quando è necessario recuperare questi documenti dalla raccolta. Come si fa a sapere se il documento recuperato contiene il formato 1 o il formato 2? Puoi verificare se il documento recuperato contiene il campo "ssn" e quindi prendere una decisione. Un'altra opzione è memorizzare il tipo di documento nel documento stesso:

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

In entrambi i casi ciò che hai ottenuto è lo spostamento dell'applicazione dello schema dal database all'applicazione -

C'è sempre uno schema, è solo una questione di dove viene implementato.

Se hai gli indici giusti, allevia il problema in una certa misura. Se la maggior parte delle tue query sono di "employeeid", sai che il documento recuperato è sempre del secondo formato, tuttavia, il resto del tuo codice che non utilizza questo indice presenterà comunque il problema sopra menzionato. Inoltre, se stai utilizzando un ODM come mongoose, applica automaticamente uno schema per te su MongoDB.

Ci sono diverse applicazioni che beneficiano di questa flessibilità. Uno scenario che viene in mente è il caso di uno schema in cui sono presenti numerosi campi/colonne opzionali. In MongoDB, non ci sono penalità per avere alcune colonne mancanti. Ogni documento può contenere solo i campi di cui ha bisogno.

Convalida del documento

A partire dalla versione 3.2.x MongoDB ora supporta il concetto di convalida dello schema utilizzando il costrutto "validator". Ciò fornisce molti livelli di convalida, quindi puoi scegliere il livello che funziona per te. Il comportamento predefinito se non si utilizza validatore è il precedente comportamento senza schema. In genere creerai i "validatori" al momento della creazione della raccolta

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

Raccolte esistenti

Le raccolte esistenti possono essere aggiornate utilizzando il comando 'collMod':

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

Livello di convalida

MongoDB supporta il concetto di 'ValidationLevel'. Il livello di convalida predefinito è "rigoroso", il che significa che gli inserimenti e gli aggiornamenti non riescono se il documento non soddisfa i criteri di convalida. Se il livello di convalida è "Moderato", applica la convalida ai documenti esistenti che soddisfano i criteri di convalida. I documenti attualmente esistenti e che non soddisfano i criteri non vengono convalidati. Sebbene sia conveniente, il livello di convalida "Moderato" può metterti nei guai su tutta la linea, quindi deve essere usato con cura.

Azione di convalida

Per impostazione predefinita, l'azione di convalida è "Errore". Se la convalida del documento non riesce, si tratta di un errore e l'aggiornamento/inserimento non riesce. Tuttavia, puoi anche impostare l'azione di convalida su "avviso", che in pratica registra la violazione dello schema nel log , ma non fallisce l'inserimento.

Quali esempi di progettazione di schemi ti potrebbero aiutare nel tuo prossimo progetto, faccelo sapere!