Última vez nos quedamos con una importación muy cruda y directa de tablas SQL en Couchbase, con un documento por fila de tabla. Pero todavía hay trabajo por hacer. Las claves primarias han cambiado en el proceso, así que tenemos que arreglar eso. Y una base de datos SQL no contiene sólo tablas. Hay otras estructuras y funciones que llevan lógica de negocio y que tendremos que mover a la capa de aplicación.
ÚNASE A
Lo primero que quiero hacer después de la importación es ejecutar JOIN en los documentos, que se puede hacer de la misma manera con una base de datos SQL porque es esencialmente un mapeo exacto. No es tan simple como ejecutar la consulta N1QL directamente. JOIN en N1QL sólo funciona en la clave de un documento, y los cambiamos en la importación para evitar la colisión. Así que tenemos que cambiar las diferentes claves foráneas. La buena noticia es que es realmente fácil de hacer con el Lenguaje de Manipulación de Datos N1QL. Hay soporte para ACTUALIZACIÓN, FUSIONAR, INSERTAR o UPSERT.
|
1 |
cbq> ACTUALIZACIÓN por defecto d SET id_idioma = "idioma::" || TOSTRING(d.id_idioma) DONDE NombreTabla = "película"; |
Esta consulta cambiará el campo language_id de todos los documentos del bucket default que contengan un campo _tableName con el valor "film". El campo language_id pasará de ser un campo de tipo Number a un String. Si tenía 1, ahora tendrá "language::1". Esto corresponderá a la clave real del documento, porque eso es lo que ha añadido el RowMapper.
El operador '||' se utiliza para concatenar cadenas. Y como language_id era un Número, necesita utilizar el método toString para convertirlo. Necesitarás ejecutar esta consulta para cada clave foránea en tu base de datos. Despues de esto deberias ser capaz de ejecutar consultas N1QL con JOIN, NEST, y UNNEST.
|
1 2 3 4 |
cbq> SELECCIONE * DESDE `por defecto` AS a ÚNASE A `por defecto` AS b EN TECLAS a.id_idioma; cbq> SELECCIONAR * DESDE `por defecto` AS a NEST `por defecto` AS b EN TECLAS a.id_idioma; |
Secuencia, Vista, Activador, Dominio y Función
Hay algunas cosas que realmente no puedes migrar directamente de una base de datos SQL a Couchbase. Más específicamente, toda la lógica de negocio que tenías en tu base de datos SQL tendrá que moverse a tu capa de aplicación. Algunas cosas son más fáciles de mover que otras. Puedes decidir si tener la lógica de negocio en la capa de datos es algo bueno o no. Aunque personalmente no me gusta, entiendo que muchas aplicaciones diferentes pueden utilizar la misma base de datos y por lo tanto la restricción expresada en el nivel de base de datos puede ser una buena cosa. Prefiero pensar que esas aplicaciones deberían depender de un servicio en lugar de llegar directamente a la base de datos.
Secuencia
Una secuencia puede verse como un Contador atómicoy es algo sencillo de crear:
|
1 2 3 4 5 6 |
JsonLongDocument rv = cubo.contador(clave, 20, 100); LOGGER.información("Delta=20, Inicial=100. El valor actual es: " + rv.contenido()); rv = cubo.contador(clave, 1); LOGGER.información("Delta=1. El valor actual es: " + rv.contenido()); |
Vistas
Una vista SQL puede verse como una tabla dinámica resultante de una consulta SQL. En Couchbase, una Ver es un índice (piensa en un índice como una tabla de dos columnas) creado dinámicamente usando una función incremental map/reduce, y depende principalmente de la complejidad de tu Vista. Una vista se utiliza para presentar los datos en un contexto diferente. En NoSQL, cuando quieres hacer eso empiezas a desnormalizar tus datos, lo que los duplica. Así que ten cuidado con lo que estás haciendo. Si estos datos necesitan ser modificados a menudo, desnormalizarlos podría no ser una buena idea (aunque las cosas podrían cambiar con la API SubDocument en la que estamos trabajando). Aquí's un ejemplo de Vista para darle una idea:
Dominio
Un dominio SQL es un nuevo tipo (basado en uno existente) con restricciones integradas. En mi ejemplo SQL, un nuevo dominio llamado tipo se define así:
|
1 2 3 4 5 6 7 |
CREAR DOMINIO público.año AS entero CONSTRAINT control_año COMPROBAR (VALOR >= 1901 Y VALOR <= 2155); ALTERAR DOMINIO público.año PROPIETARIO A postgres; |
Define un nuevo tipo llamado año a partir del tipo entero existente. Añade una restricción que diga que el valor de year debe estar comprendido entre 1901 y 2155. Para expresar esta restricción en Java, puede utilizar un marco de validación como Validador de Hibernate. Su tipo de año sería el siguiente:
|
1 2 3 4 |
@Min(1901) @Max(2155) privado int año; |
Disparador
Los disparadores son funciones SQL que se ejecutan cuando ocurre algo concreto en la base de datos, como un INSERT, DELETE o UPDATE específico. Es una gran manera de reforzar la integridad de tus datos o automatizar operaciones. No hay equivalente en Couchbase Server, así que esto tendrá que moverse a tu capa de aplicación. Por ejemplo, puedes reproducir esto usando un bus de eventos de aplicación. Esto probablemente podría hacerse usando Couchbase's DCP
Función
La mayoría de las bases de datos SQL le permiten definir sus propias funciones. Esto no es posible actualmente con N1QL. Toda la lógica que pongas en esa función debes ponerla en tu capa de aplicación.
Conclusión
Ahora deberías tener una idea decente de cómo migrar de forma sencilla de bases de datos SQL a Couchbase. No puedo dejar de enfatizar que este es el camino simple para la migración. No hay modelado de datos involucrado aquí. Una migración completa implicaría echar un buen vistazo a tu modelo de datos y ver qué puedes desnormalizar.
Háganos saber lo que piensa en los comentarios a continuación. Me encantaría saber si, por ejemplo, ya ha realizado una migración SQL y cómo lo hizo :)
