Bases de datos no relacionales

Resumen

Una base de datos no relacional, también llamada NoSQL en muchos contextos, es una base que no organiza su modelo principal como tablas relacionales con joins y constraints tradicionales. En vez de eso puede usar documentos, pares clave-valor, familias de columnas, grafos u otros modelos diseñados para patrones de acceso específicos.

Importa porque no todos los problemas encajan bien en tablas normalizadas. Algunas aplicaciones necesitan leer un agregado completo en una sola operación, escalar escrituras masivas, aceptar estructuras variables, guardar eventos, modelar relaciones de grafo o responder con latencia baja en patrones muy conocidos. Las bases no relacionales ofrecen flexibilidad y escala, pero piden diseñar pensando primero en cómo se va a consultar la data.

Alcance y supuestos

Este paquete cubre bases de datos no relacionales a nivel conceptual: documentos, clave-valor, wide-column, grafos, esquema flexible, denormalización, access patterns, consistencia y trade-offs frente a bases relacionales.

No cubre configuración vendor-specific, SDKs, motores de almacenamiento, consenso distribuido, tuning avanzado ni comparación exhaustiva de productos. Asume que entiendes datos de aplicación, CRUD, APIs y la diferencia básica entre tablas, documentos y pares clave-valor.

Modelo mental

Piensa en elegir muebles para una bodega. Una base relacional es como estanterías con cajas iguales, etiquetas estrictas y relaciones bien registradas entre cajas. Una base no relacional es elegir el mueble según cómo necesitas retirar cosas: cajones por cliente, lockers por clave, archivadores por evento o un mapa de conexiones.

No significa "sin estructura". Significa que la estructura vive en otro lugar: en documentos embebidos, claves de acceso, particiones, índices, validaciones de aplicación o reglas del proveedor. Si no diseñas esa estructura, la flexibilidad inicial se convierte en deuda.

La pregunta clave cambia. En un modelo relacional preguntas: "¿qué entidades y relaciones existen?". En muchos modelos no relacionales preguntas primero: "¿qué necesito leer y escribir rápido, con qué clave, y con qué nivel de consistencia?".

Uso práctico

Usa una base no relacional cuando el modelo o la escala favorecen un formato distinto al relacional:

• ✅ Documentos con estructura flexible, como perfiles, catálogos o configuraciones que cambian por tipo.
• ✅ Clave-valor para sesiones, preferencias, caches, feature flags o lookups simples por ID.
• ✅ Wide-column para alto volumen de escrituras y consultas por clave/partición bien conocidas.
• ✅ Grafos cuando las conexiones son el dato principal: relaciones, rutas, recomendaciones o fraude.
• ❌ No la elijas solo porque "SQL es viejo"; si necesitas joins, constraints y transacciones fuertes, una relacional puede ser más simple.
• ❌ No confundas esquema flexible con ausencia de modelo; alguien debe proteger invariantes.

Ejemplo trabajado: modelar el carrito como documento

Supón que una app necesita mostrar el carrito completo de un usuario. En una base relacional podrías tener tablas carts, cart_items, products y varios joins. En una base documental, si el patrón principal es leer el carrito completo, puedes guardar un documento orientado a esa lectura:

type CartDocument = {
  userId: string;
  currency: "CLP" | "USD";
  items: Array<{
    productId: string;
    nameSnapshot: string;
    unitPriceCents: number;
    quantity: number;
  }>;
  updatedAt: string;
};

const cart: CartDocument = {
  userId: "user_123",
  currency: "CLP",
  items: [
    {
      productId: "prod_abc",
      nameSnapshot: "Teclado mecánico",
      unitPriceCents: 5999000,
      quantity: 1,
    },
  ],
  updatedAt: "2026-07-20T00:00:00Z",
};

La lectura es directa: buscar el carrito por userId y renderizar. Pero el diseño trae decisiones:

• El nombre y precio son snapshots, no necesariamente el producto actual.
• Si el catálogo cambia, debes decidir si actualizas carritos existentes.
• Si necesitas reportes por producto, quizá debas duplicar datos, indexar o enviar eventos a otro sistema.
• Si dos dispositivos modifican el carrito, necesitas una estrategia de concurrencia.

El modelo no relacional no elimina diseño; lo mueve hacia el patrón de acceso. Primero defines la consulta crítica, luego eliges cómo guardar datos para responderla bien.

Antes de elegir NoSQL, revisa cinco preguntas:

1. ¿Cuál es la consulta principal y con qué clave empieza?
2. ¿Necesitas joins ad hoc o puedes duplicar datos de forma controlada?
3. ¿Qué consistencia necesita cada escritura y lectura?
4. ¿Cómo evolucionará el documento o registro cuando cambie el producto?
5. ¿Qué invariantes quedan en la base y cuáles quedan en la aplicación?

Una base no relacional brilla cuando el acceso es claro y el modelo encaja con ese acceso. Si el acceso es impredecible o las reglas relacionales son centrales, conviene pensarlo dos veces.

Evidencia

• IBM Think, What Is a NoSQL Database? define NoSQL como un enfoque de diseño que permite almacenar y consultar datos fuera de las estructuras tradicionales de bases relacionales.
• AWS documentation, What is Amazon DynamoDB? describe DynamoDB como una base NoSQL que soporta modelos clave-valor y documento.
• MongoDB documentation, Data Modeling in MongoDB explica que el esquema flexible de MongoDB permite mejorar iterativamente el modelo de datos durante el desarrollo.