Diseño de esquema MongoDB

Cuando se introdujo MongoDB hace unos años, una de las características importantes que se promocionaba era la capacidad de ser "sin esquema". ¿Qué significa esto para sus documentos?

El diseño del esquema de MongoDB no impone ningún esquema en los documentos almacenados en una colección. MongoDB esencialmente almacena documentos JSON, y cada documento puede contener cualquier estructura que desee. Considere algunos ejemplos de nuestra colección de "contactos" a continuación. Aquí hay un documento que puede almacenar:

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

Ahora el segundo documento almacenado en la colección puede tener este formato:

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

Es genial que puedas almacenar estos dos documentos en la misma colección. El problema, sin embargo, comienza cuando necesita recuperar estos documentos de la colección. ¿Cómo sabe si el documento recuperado contiene el formato 1 o el formato 2? Puede verificar si el documento recuperado contiene el campo 'ssn' y ​​luego tomar una decisión. Otra opción es almacenar el tipo de documento en el propio documento:

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

En ambos casos, lo que ha logrado es mover la aplicación del esquema de la base de datos a la aplicación -

Siempre hay un esquema, solo es cuestión de dónde se implementa.

Si tiene los índices correctos, el problema se alivia hasta cierto punto. Si la mayoría de sus consultas son por 'employeeid', sabe que el documento recuperado siempre tiene el segundo formato; sin embargo, el resto de su código que no usa este índice seguirá teniendo el problema mencionado anteriormente. Además, si está utilizando un ODM como mongoose, automáticamente ya aplica un esquema para usted sobre MongoDB.

Existen varias aplicaciones que se benefician de esta flexibilidad. Un escenario que me viene a la mente es el caso de un esquema en el que hay varios campos/columnas opcionales. En MongoDB, no hay penalización por tener algunas columnas faltantes. Cada documento solo puede contener los campos que necesita.

Validación de documentos

A partir de la versión 3.2.x, MongoDB ahora admite el concepto de validación de esquema mediante la construcción "validador". Esto proporciona muchos niveles de validación, por lo que puede elegir el nivel que más le convenga. El comportamiento predeterminado si no usa el validador es el comportamiento sin esquema anterior. Por lo general, creará los "validadores" en el momento de la creación de la colección

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

Colecciones existentes

Las colecciones existentes se pueden actualizar usando el comando 'collMod':

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

Nivel de validación

MongoDB admite el concepto de 'ValidationLevel'. El nivel de validación predeterminado es "estricto", lo que significa que las inserciones y actualizaciones fallan si el documento no cumple con los criterios de validación. Si el nivel de validación es "Moderado", aplica la validación a los documentos existentes que cumplen con los criterios de validación. Los documentos que existen actualmente y no cumplen con los criterios no se validan. Si bien es conveniente, el nivel de validación "Moderado" puede causarle problemas en el futuro, por lo que debe usarse con cuidado.

Acción de validación

Por defecto, la acción de validación es 'Error'. Si su documento falla en la validación, es un error y la actualización/inserción falla. Sin embargo, también puede configurar la acción de validación para "advertir", que básicamente registra la violación del esquema en el registro, pero no falla la inserción.

¿Qué ejemplos de diseño de esquema te ayudarían en tu próximo proyecto? ¡Háznoslo saber!