Cuando explicamos qué es NoSQL, y cómo encaja Couchbase en ese panorama, solemos recibir preguntas sobre Bases de Datos Relacionales, y no podemos evitar comparar ambas. Aunque su arquitectura es bastante diferente, podemos encontrar algunas similitudes en los conceptos. Esta es una lectura de dos minutos para entender esas similitudes.
Tabla/Columna Documento V.S.
Empecemos adoptando la perspectiva del desarrollador. En su código, el desarrollador a menudo manipula objetos de dominio. Algunos de estos objetos se leen de una base de datos o se persisten en una base de datos. En una BD relacional un objeto está representado por una o más Filas de Tablas formadas por Columnas. Una columna tiene un nombre y un tipo. En una BD documental, un documento es tradicionalmente un par clave/valor donde el valor es un documento JSON (una cadena JSON). Utilizamos el término Documento DB cuando la clave / valor DB da al desarrollador una manera de consultar el documento basado en el valor.
Un documento JSON puede tener múltiples campos y cada campo tiene un nombre y un tipo. Así que, si seguimos con la analogía, JSON permite tener un conjunto flexible de columnas por documento. Esto significa que no tienes que definir todas las tablas/columnas una vez. Usted tiene la flexibilidad para modificar que como mejor le parezca en un documento DB. Esto es realmente lo que sin esquema se trata. No se trata de no tener esquema, sino de poder cambiarlo fácilmente. Los campos tipificados del documento JSON hacen del esquema, un esquema flexible e inferido.
No puedo poner sobre la mesa el tema de la granularidad y no hablar de nuestro nuevo API de subdocumentos. Esto aparece en Couchbase 4.5. En una base de datos Relation puedes modificar o leer campos específicos de tu objeto porque puedes modificar o leer una fila particular de una columna particular. El equivalente con un documento JSON sería modificar o leer un campo particular de tu documento JSON. Y esto es exactamente lo que la API de subdocumentos te permite hacer.
Cuando ejecutas una consulta SQL, la cláusula FROM se refiere a tablas. Couchbase también tiene un lenguaje de consulta declarativo llamado N1QL. Es un superconjunto de SQL y como tal permite hacer JOINs entre otras cosas. genial cosas. Y como no hay tablas en Couchbase, la cláusula FROM se aplica a un Bucket. Las consultas JOIN también se realizan entre Buckets. Y esto nos lleva al siguiente tema.
Esquema V.S. Bucket
Las tablas y columnas se almacenan normalmente en lo que se llama un Esquema o Base de Datos (con otras cosas como procedimientos almacenados, vistas materializadas, contadores y más). Con Couchbase, los documentos se almacenan en un Bucket. El conjunto de opciones y capacidades son bastante diferentes. Si tomamos la seguridad por ejemplo. En una base de datos relacional, puedes llegar a especificar permisos sobre una columna concreta de una tabla. En un Bucket, sólo puedes almacenar pares k/v. Así que sólo puede conceder permisos en este. Lo que significa que solo puedes conceder permisos de lectura o lectura/escritura en un Bucket para un usuario en particular. Así que si quieres reforzar la seguridad tiene que hacerse a nivel de aplicación. Esta es una de las compensaciones que tienes que hacer ahora mismo cuando eliges una BD NoSQL, parte de la lógica de aplicación que estaba en la BD de Relación se desplazará a la capa de aplicación. Podemos discutir si esto es bueno o no.
Como desarrollador prefiero tener la lógica en el código, pero esto es sólo mi opinión. Podemos empezar una discusión sobre esto en los comentarios de abajo :) ¡Háganos saber lo que piensa! También podríamos llevar el tema más allá de este ámbito y hablar de clusters, replicación y sharding, pero ya no sería una lectura de 2 minutos :)
