MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Conception de schéma MongoDB :il y a toujours un schéma

Conception de schéma MongoDB

Lorsque MongoDB a été introduit il y a quelques années, l'une des fonctionnalités importantes vantées était la possibilité d'être "sans schéma" - Qu'est-ce que cela signifie pour vos documents ?

La conception de schéma MongoDB n'applique aucun schéma sur les documents stockés dans une collection. MongoDB stocke essentiellement des documents JSON, et chaque document peut contenir la structure de votre choix. Considérez quelques exemples de notre collection de « contacts » ci-dessous. Voici un document que vous pouvez stocker :

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

Désormais, le deuxième document stocké dans la collection peut être de ce format :

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

C'est plutôt cool que vous puissiez stocker ces deux documents dans la même collection. Le problème, cependant, commence lorsque vous devez récupérer ces documents à partir de la collection. Comment savoir si le document récupéré contient le format 1 ou le format 2 ? Vous pouvez vérifier si le document récupéré contient le champ « ssn », puis prendre une décision. Une autre option consiste à stocker le type du document dans le document lui-même :

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

Dans ces deux cas, vous avez réussi à déplacer l'application du schéma de la base de données vers l'application -

Il y a toujours un schéma, c'est juste une question d'où il est implémenté.

Si vous avez les bons index, cela atténue le problème dans une certaine mesure. Si la majorité de vos requêtes sont par "employeeid", vous savez que le document récupéré est toujours du deuxième format - cependant, le reste de votre code qui n'utilise pas cet index aura toujours le problème mentionné ci-dessus. De plus, si vous utilisez un ODM comme la mangouste, il applique déjà automatiquement un schéma pour vous au-dessus de MongoDB.

Plusieurs applications bénéficient de cette flexibilité. Un scénario qui vient à l'esprit est le cas d'un schéma où il y a un certain nombre de champs/colonnes optionnels. Dans MongoDB, il n'y a pas de pénalité pour avoir des colonnes manquantes. Chaque document ne peut contenir que les champs dont il a besoin.

Validation des documents

À partir de la version 3.2.x, MongoDB prend désormais en charge le concept de validation de schéma à l'aide de la construction "validator". Cela fournit de nombreux niveaux de validation - vous pouvez donc choisir le niveau qui vous convient. Le comportement par défaut si vous n'utilisez pas de validateur est le comportement sans schéma précédent. En règle générale, vous créerez les "validateurs" au moment de la création de la collection

db.createCollection( "contacts",
   { validator: { $or:
      [
         { employeeid: { $exists: true }},
         { SSN: { $exists: true } }
      ]
   }
} )
Créez des validations de schéma dans MongoDB afin de pouvoir choisir le niveau dont vous avez besoinClick To Tweet

Collections existantes

Les collections existantes peuvent être mises à jour à l'aide de la commande "collMod" :

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

Niveau de validation

MongoDB prend en charge le concept de "ValidationLevel". Le niveau de validation par défaut est "strict", ce qui signifie que les insertions et les mises à jour échouent si le document ne répond pas aux critères de validation. Si le niveau de validation est « Modéré », il applique la validation aux documents existants qui répondent aux critères de validation. Les documents qui existent actuellement et ne répondent pas aux critères ne sont pas validés. Bien que pratique, le niveau de validation "Modéré" peut vous causer des ennuis sur toute la ligne. Il doit donc être utilisé avec précaution.

Action de validation

Par défaut, l'action de validation est « Erreur ». Si votre document échoue à la validation, il s'agit d'une erreur et la mise à jour/l'insertion échoue. Cependant, vous pouvez également définir l'action Validation sur "warn" qui enregistre essentiellement la violation de schéma dans le journal, mais n'échoue pas l'insertion.

Quels exemples de conception de schéma vous aideraient dans votre prochain projet, faites-le nous savoir !