¿Cuándo es apropiada una base de datos sin esquema?

El modelo de base de datos sin esquema sería un buen reemplazo para el modelo de valor de atributo de entidad (EAV). Por lo general, EAV se elige porque los atributos para una entidad no se conocen de antemano (o no se requieren todos los atributos para una entidad), por lo que la entidad no se puede modelar de manera eficiente en un modelo relacional. El modelo sin esquema logra el mismo resultado de EAV, sin sus inconvenientes, como los requisitos de JOIN, etc. En un modelo sin esquema (al menos en NoSQL DBs como MongoDB), cada documento puede tener sus propios atributos y es bastante autónomo . El modelo sin esquema funciona bien cada vez que fuerza el ajuste de un modelo en relacional.

Cuando sus políticas corporativas requieren que usted:

• pagar más por los servidores en el clúster de base de datos que por los servidores independientes
• proporcionar scripts SQL / DDL de actualización y reversión para cada implementación (en lugar de usar una herramienta automatizada como migraciones Rails o Liquibase)
• reduzca la velocidad de cada implementación haciendo que un DBA cierre la sesión en todos los SQL antes mencionados, incluso si el DBA comprende menos SQL que la mayoría de los desarrolladores
• ralentizar cada implementación al considerarlas como un “riesgo para la infraestructura compartida” si tocan una base de datos de alguna manera

… entonces una base de datos sin esquema puede ser una forma útil de evitar la burocracia sin sentido y obtener implementaciones automatizadas para la producción.

Todavía tiene que hacer algo si la estructura de sus datos cambia, pero hacerlo en código como una tarea en segundo plano podría darle más flexibilidad que un solo script SQL / DDL de big bang de todos modos.