Consultar cada modelo

En la consola de MongoDB toda operación se escribe con la misma forma de tres piezas: el objeto que representa la base de datos, el nombre de la colección y el método que se aplica. En db.cursos.insertOne, db es la base activa, cursos es la colección y insertOne es el método.

No hay que crear la colección antes de usarla. Si se escribe en una colección que no existe, el motor la crea en ese momento con la primera inserción, coherentemente con la idea de que no hay esquema que declarar.

// Insertar un documento. Si la colección no existe, se crea aquí.
db.cursos.insertOne({ titulo: 'TAI Curso Largo', horas: 300, activo: true })

// Modificar el primer documento que cumpla el filtro.
db.cursos.updateOne({ titulo: 'TAI Curso Largo' }, { $set: { activo: false } })

// Borrar todos los que cumplan el filtro.
db.cursos.deleteMany({ activo: false })

Los métodos van en parejas de uno y muchos: insertOne e insertMany, updateOne y updateMany, deleteOne y deleteMany. La diferencia no es cosmética: updateOne modifica solo el primer documento que encaja con el filtro, aunque encajen mil.

Para modificar hay que usar un operador como $set. Si se pasa el objeto sin operador, se reemplaza el documento entero y desaparecen los campos que no se hayan repetido.

El método de lectura es find, y admite dos argumentos con papeles muy distintos, que es donde más se falla.

• El primer argumento es el filtro: qué documentos se quieren. Decide cuántos resultados salen.
• El segundo argumento es la proyección: qué campos de cada documento se quieren. Decide qué ancho tiene cada resultado, no cuántos hay. Se marca con 1 el campo que se incluye y con 0 el que se excluye.

Las comparaciones que no son de igualdad se escriben con operadores que empiezan por dólar: $gt (mayor que), $gte (mayor o igual), $lt y $lte para las contrarias, $ne (distinto) y $in (que esté en una lista).

Y find no devuelve la lista de resultados, devuelve un cursor: un puntero desde el que se van pidiendo los documentos poco a poco. Por eso se le pueden encadenar métodos como sort para ordenar o limit para cortar el número de resultados, y por eso una consulta sobre millones de documentos no se trae la base entera a memoria.

db.cursos.find(
  { horas: { $gte: 200 } },        // filtro: qué documentos
  { titulo: 1, horas: 1, _id: 0 }  // proyección: qué campos
)
.sort({ horas: -1 })               // el cursor admite encadenar
.limit(5)

Filtro y proyección responden a preguntas distintas: cuáles y qué campos. El cursor es lo que permite ordenar y limitar sin traerse todo.

En Redis la clave no guarda un valor cualquiera, sino un valor de un tipo concreto, y cada tipo trae sus propias operaciones. Saber a qué tipo pertenece cada comando es lo que se pregunta, y hay una pista buena: la inicial del comando suele delatar el tipo.

SET sesion:8421 activa
GET sesion:8421

LPUSH avisos:8421 "Nuevo simulacro publicado"
LRANGE avisos:8421 0 9

SADD temas-repaso:8421 5 12 27
SMEMBERS temas-repaso:8421

HSET alumno:8421 nombre Ana curso largo
HGET alumno:8421 curso
HGETALL alumno:8421

La L de LPUSH y LRANGE es de lista, la S de SADD y SMEMBERS es de set, y la H de HSET, HGET y HGETALL es de hash. Con esa regla se acierta casi cualquier pregunta de comandos de Redis.

Los otros dos modelos tienen lenguajes propios que conviene reconocer de vista, aunque no haya que escribirlos de memoria.

Cassandra usa CQL, cuya sintaxis se parece deliberadamente a SQL para bajar la barrera de entrada. El parecido es solo de forma: no hay uniones entre tablas ni subconsultas, y la clave primaria manda mucho más que en SQL, porque su primera parte decide en qué nodo vive la fila y el resto decide cómo quedan ordenadas las columnas dentro de ella.

CREATE TABLE academia.intentos (
  alumno   uuid,
  fecha    timestamp,
  tema     int,
  aciertos int,
  PRIMARY KEY (alumno, fecha)
);

-- La consulta natural: todo lo de un alumno, que vive en un solo nodo.
SELECT tema, aciertos FROM academia.intentos
WHERE alumno = 8f2c1a94-0000-0000-0000-000000000000
  AND fecha > '2026-01-01';

Neo4j usa Cypher, que no se parece a SQL en nada: se escribe dibujando el patrón que se busca. Los paréntesis son nodos, los corchetes entre flechas son relaciones, y la consulta consiste en describir la forma del trozo de grafo que interesa y dejar que el motor lo encuentre.

MATCH (a:Alumno)-[:FALLA]->(t:Tema)<-[:FALLA]-(companero:Alumno)
WHERE a.id = 8421
RETURN companero.nombre, count(t) AS temas_en_comun
ORDER BY temas_en_comun DESC
LIMIT 5

CQL se parece a SQL pero no hace uniones. Cypher no se parece a SQL porque describe un patrón de nodos y relaciones en lugar de un conjunto de filas.