2010-05-16 10 views
5

Según tengo entendido, puede ingresar cualquier información no estructurada en una base de datos orientada a documentos. Imaginemos un documento como este:Base de datos orientada a documentos: ¿qué sucede si cambian las definiciones de documento?

{ 
    name: 'John Blank', 
    yearOfBirth: 1960 
} 

Más tarde, en una nueva versión, esta estructura se readaptado a

{ 
    firstname: 'John', 
    lastname: 'Blank', 
    yearOfBirth: 1960 
} 

¿Cómo se hace esto con las bases de datos orientadas a documentos? ¿Tiene que preparar scripts de fusión, que alteran todas sus entradas en la base de datos? ¿O hay mejores formas de manejar los cambios en la estructura?

Respuesta

3

La refabricación aquí implica que hay una asignación determinista del esquema anterior al nuevo esquema. Entonces, la opción más efectiva es hacer lo mismo que harías con una base de datos SQL y realmente actualizar los documentos.

Las bases de datos orientadas a documentos le dan otra opción, aunque depende de qué DODB y cómo lo esté utilizando en el front-end. Esa opción es simplemente dejar los datos solos y admitir la definición "antigua" en su aplicación como una especie de opción de compatibilidad con versiones anteriores. En otras palabras, estás haciendo estas traducciones sobre la marcha, a diferencia de una actualización permanente de una sola vez.

Esto no es realmente una opción con una base de datos SQL porque tendrías que mantener la columna obsoleta alrededor y posiblemente indexada. Con un DODB, realmente no está desperdiciando ningún espacio de datos o índice. Tendría que sopesar las ventajas contra las desventajas.

La desventaja principal es, obviamente, la inconsistencia, que podría crecer con el tiempo y provocar errores. Otra desventaja es posiblemente el gasto computacional de hacer esto sobre la marcha, o la incapacidad de usar efectivamente la nueva estructura (por ejemplo, es posible que desee indexar solo el lastname). Entonces, la mayoría de las veces, creo que elegiría ejecutar una actualización masiva.

Sin embargo, existe una clara ventaja en la conservación de los documentos antiguos; si no está seguro de que su refactorización sea perfecta, por ejemplo, si los datos en su columna name no siguen una convención coherente, tal vez en algunos casos sea lastname, firstname y en otros casos sea firstname lastname y en otros sea company name - entonces hacer sus conversiones sobre la marcha sin realizar una actualización permanente le permite refinar el mapeo a lo largo del tiempo, por lo que puede usar los campos firstname y lastname cuando estén disponibles, pero recurra al name juego de adivinanzas para datos heredados.

Como dije, probablemente reservaría la segunda opción para casos excepcionales, en los que no estoy seguro de que pueda hacer la "refactorización" correcta para cada registro/documento. Sin embargo, es una opción disponible para usted que realmente no tiene con otros tipos de bases de datos.

Aparte de esos dos, no veo ninguna otra alternativa clara. Es una especie de decisión binaria; o actualizas permanentemente los datos existentes o no.

Cuestiones relacionadas