Archivos y bases de datos: almacenamiento relacional y no relacional, consultas y transacciones

Por qué los programas necesitan un lugar donde guardar los datos

Un programa en ejecución mantiene sus datos de trabajo en memoria (RAM), que es rápida pero lo olvida todo cuando el programa se detiene o la máquina se reinicia (consulta qué es el software). Todo lo que deba sobrevivir a un reinicio, como la cuenta de un cliente, un pedido o una cita en un hospital, tiene que escribirse en un almacenamiento que conserve su contenido sin corriente: un disco duro o una unidad de estado sólido. Los datos que sobreviven de esta forma se llaman persistentes, y decidir cómo persistirlos es una de las primeras decisiones de cualquier sistema y de las que más duran.

La forma más sencilla de persistir datos es un archivo: una secuencia de bytes con nombre que el sistema operativo guarda en disco. Los archivos son excelentes para cosas que por naturaleza son documentos completos: imágenes, PDF, videos, configuración, logs, informes exportados. Los sistemas suelen guardarlos en un almacenamiento de objetos en la nube (un servicio que guarda archivos por nombre) y registrar en otro lugar solo una referencia.

Los archivos se vuelven un problema cuando muchos usuarios leen y modifican a la vez pequeños fragmentos de datos estructurados. Imagina una tienda que guarda todos sus pedidos en un único archivo de hoja de cálculo. Dos clientes pagan en el mismo instante: ¿qué cambio prevalece? El servidor se cae a mitad del guardado: ¿el archivo queda mitad antiguo, mitad nuevo? Un agente de soporte quiere los pedidos de un cliente: ¿tiene el programa que leer el archivo entero? Alguien escribe un número de cliente que no existe: ¿quién se lo impide? Cada programa que usara el archivo tendría que resolver cada uno de estos problemas, y de la misma manera.

Qué es una base de datos

Una base de datos es una colección organizada de datos, y el programa que se ocupa de ella es un sistema de gestión de bases de datos (DBMS), como PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database o SQLite. A menudo se dice "la base de datos" para ambas cosas. El DBMS resuelve los problemas de los archivos una sola vez, para todos: permite que muchos usuarios trabajen a la vez sin pisarse, encuentra los datos rápidamente, rechaza los datos que incumplen las reglas y vuelve a un estado correcto tras una caída.

La analogía es una biblioteca. Un montón de papeles sobre una mesa funciona si eres su único usuario. Una biblioteca tiene un catálogo, reglas sobre dónde va cada cosa, un registro de quién se ha llevado qué y un bibliotecario que no deja que dos personas se lleven el mismo ejemplar. Las aplicaciones no tocan las estanterías; se lo piden al bibliotecario.

En la mayoría de los sistemas empresariales, el DBMS se ejecuta como un proceso servidor propio, a menudo en su propia máquina, y las aplicaciones se comunican con él a través de la red (consulta cómo se comunican las computadoras). SQLite es una excepción muy conocida: es una biblioteca que se ejecuta dentro de la aplicación y guarda toda la base de datos en un único archivo, por eso se encuentra en teléfonos, navegadores y pequeñas herramientas.

Bases de datos relacionales: tablas, claves y relaciones

El tipo de base de datos más utilizado es la base de datos relacional, basada en un modelo publicado por Edgar F. Codd, de IBM, en 1970. Los datos viven en tablas. Cada tabla describe un tipo de cosa (clientes, pedidos, productos). Cada fila es una instancia de esa cosa (un cliente), y cada columna es un dato sobre ella (nombre, dirección de correo electrónico, fecha de alta), con un tipo declarado, como entero, texto, fecha o decimal.

Cada tabla tiene una clave primaria: una columna (o combinación de columnas) cuyo valor es único para cada fila y nunca está vacío, como customer_id. Una clave foránea es una columna de una tabla que contiene la clave primaria de una fila de otra tabla. Un pedido tiene una columna customer_id, que indica qué cliente lo hizo. Declararla como clave foránea le indica al DBMS que rechace un pedido para el cliente 999 si no existe ningún cliente 999: esto se llama integridad referencial.

El conjunto completo de tablas, columnas, tipos, claves y reglas es el esquema. El esquema es un contrato: cada programa que usa la base de datos puede confiar en que un pedido siempre tiene un cliente válido y un precio que es un número. Cambiar un esquema más adelante, cuando millones de filas y varios programas dependen de él, es posible pero exige cuidado, y por eso la evolución del esquema tiene su propia sección en el Capítulo 7.

Los diseños relacionales intentan guardar cada dato una sola vez. La dirección de correo electrónico del cliente vive en una fila de la tabla de clientes, no copiada en cada pedido. Esto se llama normalización. Significa que una actualización ocurre en un solo lugar y no puede dejar atrás copias contradictorias. El precio de este orden es que responder a una pregunta a menudo obliga a combinar tablas, que es para lo que sirven los joins.

Hacer preguntas con SQL

SQL (Structured Query Language, que se pronuncia "ese-cu-ele" o, en inglés, "sequel") es el lenguaje que se usa para trabajar con bases de datos relacionales. Se desarrolló en IBM en la década de 1970 y se convirtió en norma ANSI e ISO a finales de la década de 1980; todos los DBMS relacionales importantes lo hablan, cada uno con pequeñas diferencias de dialecto. SQL es declarativo: describes el resultado que quieres, no los pasos para encontrarlo. El planificador de consultas del DBMS elige los pasos, por ejemplo si leer una tabla entera o usar un índice.

Un join combina filas de dos o más tablas haciendo coincidir columnas, normalmente una clave foránea con la clave primaria a la que remite. La segunda consulta de abajo lista cada línea de los pedidos de un cliente junto con el nombre del producto, usando tres tablas a la vez.

-- One customer's orders since 1 October, newest first
SELECT order_id, status, placed_at
FROM orders
WHERE customer_id = 42
  AND placed_at >= '2026-10-01'
ORDER BY placed_at DESC;

-- Each order line with the product's name (a join)
SELECT o.order_id, p.name, i.quantity, i.unit_price
FROM orders AS o
JOIN order_items AS i ON i.order_id = o.order_id
JOIN products AS p ON p.product_id = i.product_id
WHERE o.customer_id = 42;

INSERT, UPDATE y DELETE modifican datos, y CREATE TABLE define el esquema. El código de las aplicaciones suele enviar SQL a través de un mapeador objeto-relacional (ORM), una biblioteca que convierte filas en objetos. Los ORM ahorran escritura, pero ocultan el SQL que realmente se envía; un problema de rendimiento clásico es un ORM que lanza sin avisar una consulta por fila en lugar de un único join.

Índices: el índice del libro, no el libro entero

Sin ayuda, la única forma que tiene la base de datos de encontrar todos los pedidos del cliente 42 es leer cada fila de la tabla de pedidos y comprobarla una por una: un recorrido completo de la tabla, que es O(n) en la notación de datos y algoritmos. Un índice de base de datos es una estructura de datos adicional y ordenada que relaciona los valores de una columna con las filas que los contienen, igual que el índice al final de un libro relaciona palabras con números de página. La mayoría de las bases de datos relacionales usan por defecto un árbol B (B-tree), un árbol ancho, poco profundo y siempre equilibrado que encuentra un valor en O(log n) pasos.

Las claves primarias se indexan automáticamente. Los demás índices se añaden de forma deliberada, para las columnas por las que las consultas filtran, combinan u ordenan: CREATE INDEX idx_orders_customer ON orders (customer_id);. Los índices no son gratis. Cada inserción, actualización o borrado debe actualizar también cada índice de la tabla, y cada índice ocupa espacio en disco y memoria. Una tabla con quince índices lee rápido y escribe despacio. Elegir índices es un compromiso guiado por las consultas que el sistema ejecuta realmente, lo que constituye un primer ejemplo del compromiso entre espacio y tiempo que atraviesa toda la arquitectura.

Transacciones y ACID: la transferencia bancaria

Mover 100 libras de la cuenta de Alice a la de Bob requiere dos cambios: restar 100 a Alice y sumar 100 a Bob. Si el servidor se cae después del primer cambio y antes del segundo, 100 libras han desaparecido. Si dos transferencias desde la cuenta de Alice se ejecutan a la vez, ambas podrían ver un saldo de 150 y ambas podrían tener éxito, dejándola en descubierto. Una transacción agrupa varias operaciones en una unidad de trabajo que o bien se completa por entero (commit) o bien no tiene ningún efecto (rollback).

Las garantías que ofrece una transacción se resumen como ACID, un acrónimo acuñado por Theo Härder y Andreas Reuter en 1983, a partir de trabajos anteriores de Jim Gray:

import sqlite3

conn = sqlite3.connect("bank.db")
# The accounts table was created with CHECK (balance >= 0)

def transfer(from_id, to_id, amount):
    try:
        with conn:  # one transaction: commit on success, rollback on error
            debit = conn.execute(
                "UPDATE accounts SET balance = balance - ? WHERE id = ?",
                (amount, from_id))
            credit = conn.execute(
                "UPDATE accounts SET balance = balance + ? WHERE id = ?",
                (amount, to_id))
            if debit.rowcount != 1 or credit.rowcount != 1:
                raise ValueError("No such account")  # forces a rollback
        return "Transfer complete"
    except (sqlite3.Error, ValueError):
        return "Transfer refused: no account was changed"

Fíjate en la comprobación de rowcount (el número de filas que ha cambiado cada actualización): para la base de datos, una actualización que no coincide con ninguna cuenta no es un error, así que el propio código debe tratarla como tal. Hay otros dos detalles importantes más allá de este ejemplo. Los marcadores ? pasan los valores por separado del texto SQL, que es la defensa estándar contra la inyección SQL, un ataque en el que la entrada del usuario se cuela en una consulta como si fuera código (el Capítulo 8 vuelve sobre esto). Y la promesa de durabilidad se cumple gracias a un registro de escritura anticipada (write-ahead log): el DBMS anota cada cambio en un registro en disco al que solo se añaden datos antes de confirmar el commit, de modo que tras una caída puede repetir o deshacer trabajo hasta llegar a un estado correcto.

El aislamiento es la propiedad más sutil. El aislamiento completo (llamado serializable) es seguro pero limita cuánto trabajo puede ejecutarse en paralelo, así que las bases de datos ofrecen niveles de aislamiento más débiles que cambian algo de protección por velocidad, y muchas usan por defecto un nivel más débil. Qué anomalías permite cada nivel se trata en transacciones y aislamiento. Por ahora, la idea clave es que una sola base de datos ofrece garantías fuertes y bien conocidas dentro de una transacción, y que esas garantías son mucho más difíciles de conseguir cuando los datos están repartidos entre varias bases de datos o servicios.

NoSQL: otras formas de datos

Las bases de datos relacionales no son la única opción. NoSQL es un nombre genérico, popularizado en un encuentro de 2009 en San Francisco, para las bases de datos que no usan el modelo relacional. Surgieron para manejar volúmenes muy grandes repartidos entre muchas máquinas, formas de datos flexibles y patrones de acceso que las tablas atienden con dificultad. El nombre dice lo que no son, así que abarca familias bastante distintas.

Los profesionales no se ponen de acuerdo sobre la opción por defecto. Un grupo dice que hay que empezar con una base de datos relacional salvo que haya un motivo claro para no hacerlo: SQL es ampliamente conocido, las transacciones y los joins son potentes, y los sistemas relacionales modernos también guardan bien documentos JSON. El otro grupo dice que hay que elegir desde el principio el almacén que encaje con el patrón de acceso, porque un almacén documental o clave-valor puede ser más sencillo y escalar de forma más barata con la carga de trabajo adecuada. Ambos coinciden en que muchos sistemas reales usan más de un tipo, cada uno donde encaja, lo que se llama persistencia políglota. La sección del Capítulo 7 sobre cómo elegir una base de datos ofrece una forma estructurada de decidir.

Ejemplo práctico: el esquema de una tienda en línea

Piensa en una pequeña tienda en línea. Necesita saber quiénes son sus clientes, qué vende y quién ha pedido qué. Un primer intento podría ponerlo todo en una sola tabla con una fila por pedido y las columnas product1, product2, product3. Eso se rompe en cuanto alguien pide cuatro cosas, y copia el nombre y la dirección del cliente en cada pedido.

Copias de seguridad, recuperación y bases de datos gestionadas

Los discos fallan, la gente ejecuta el DELETE equivocado, el software tiene errores y hay atacantes que cifran los datos para pedir un rescate. Una copia de seguridad es una copia de los datos guardada en un lugar separado, a partir de la cual se puede restaurar la base de datos. Hay tres hábitos profesionales importantes. Una copia de seguridad que nunca se ha restaurado es una esperanza, no una copia de seguridad, así que los equipos ensayan las restauraciones y miden cuánto tardan. Las copias se guardan en más de un lugar (una regla práctica habitual es tener tres copias, en dos tipos de soporte, una fuera de las instalaciones). Y una réplica, una segunda base de datos que copia continuamente la primera, protege contra el fallo de una máquina, pero no contra los errores: un DELETE erróneo llega a la réplica en milisegundos. Muchas bases de datos pueden combinar una copia de seguridad completa periódica con el registro de transacciones guardado para restaurar a cualquier momento, lo que se llama recuperación a un punto en el tiempo.

Administrar bien una base de datos (aplicar parches, ajustarla, replicarla, hacer copias de seguridad y restaurarla a las tres de la mañana) es un trabajo especializado que nunca termina, así que los proveedores de nube venden bases de datos gestionadas: Amazon RDS, Azure SQL Database y Google Cloud SQL son ejemplos. El proveedor se encarga de las máquinas, las actualizaciones de software, las copias de seguridad automáticas y el failover a una copia en reserva; el cliente sigue siendo responsable del esquema, las consultas, los índices, los permisos de acceso y el costo. Los servicios gestionados se tratan de forma más amplia en servidores y la nube.

Por qué esto importa para la arquitectura

Los datos suelen durar más que el código que los rodea: las aplicaciones se reescriben cada pocos años, mientras que los registros de clientes y los historiales médicos se conservan durante décadas. Las decisiones sobre dónde viven los datos, qué tipo de base de datos los guarda, qué programa es su propietario y qué garantías necesitan son, por tanto, de las más costosas de revertir. Varias grandes cuestiones de arquitectura surgen directamente de esta sección: si cada servicio debe tener su propia base de datos (propiedad de los datos), qué base de datos sirve para cada trabajo (cómo elegir una base de datos) y cómo mantener los datos correctos cuando una acción de negocio afecta a varias bases de datos, donde ya no se dispone de una única transacción ACID (sagas). Cuando un arquitecto pregunta "¿dónde está la fuente de verdad de esto?", esta sección es el motivo.