Dado que una base de datos nosql puede contener grandes cantidades de datos, no puede migrarla en el sentido normal de rdbms. En realidad, no puede hacerlo para rdbms tan pronto como sus datos superen cierto umbral de tamaño. No es práctico desconectar su sitio durante un día para agregar un campo a una tabla existente, por lo que con rdbms termina haciendo parches feos como agregar nuevas tablas solo para el campo y hacer uniones para llegar a los datos. En el mundo de nosql puedes hacer varias cosas.
- Como otros sugirieron, puede escribir su código para que maneje diferentes 'versiones' del posible esquema. esto suele ser más simple de lo que parece. Muchos tipos de cambios de esquema son triviales para codificar. por ejemplo, si desea agregar un nuevo campo al esquema, simplemente agréguelo a todos los registros nuevos y estará vacío en todos los registros antiguos (no obtendrá errores de "el campo no existe" ni nada;). si necesita un valor 'predeterminado' para el campo en los registros antiguos, se hace de manera demasiado trivial en el código.
- Otra opción y, de hecho, la única opción sensata que avanza con cambios de esquema no triviales, como cambios de nombre de campo y cambios estructurales, es almacenar schema_version en CADA registro y tener un código para migrar datos de cualquier versión a la siguiente en LEER . es decir, si su versión de esquema actual es 10 y lee un registro de la base de datos con la versión 7, entonces su capa de base de datos debería llamar a migrate_8, migrate_9 y migrate_10. De esta forma los datos a los que se acceda serán migrados paulatinamente a la nueva versión. y si no se accede, a quién le importa qué versión es;)
