Bases de datos: el lugar donde los datos tienen un hogar permanente

Imagina este escenario: una app de pedidos tiene 50 empleados accediendo a los mismos datos al mismo tiempo. Un empleado está leyendo el stock de un producto mientras otro lo está vendiendo. ¿Qué stock es el correcto? ¿Y si dos empleados venden la última unidad al mismo tiempo? ¿Quién gana? Con ficheros simples (como una hoja de cálculo compartida), esto es un desastre. Con una base de datos, está resuelto.

Una base de datos es un sistema de software especializado en almacenar, organizar y servir datos a múltiples usuarios simultáneamente con garantías de seguridad, consistencia y velocidad. Piensa en la diferencia entre un cuaderno personal (archivo) y una biblioteca pública (base de datos): el cuaderno es tuyo, lo usas solo tú, lo organizas como quieres. La biblioteca tiene un catálogo, reglas de préstamo, permite que 1000 personas la usen al mismo tiempo, y se asegura de que nadie se lleve un libro que ya está prestado.

### ¿Por qué no vale con archivos?

Los archivos (CSV, JSON, Parquet) son perfectos para almacenamiento y procesamiento en lote: leer un archivo, transformarlo, escribir otro. Pero tienen problemas graves cuando necesitas cosas que las aplicaciones reales necesitan:

• ▹Acceso concurrente: 50 personas leyendo/escribiendo al mismo tiempo sin pisarse.
• ▹Transacciones: si una transferencia bancaria falla a mitad, no quiero quedarme sin dinero en ambas cuentas.
• ▹Consultas rápidas: encontrar un cliente por email entre 10 millones en milisegundos.
• ▹Seguridad: que el becario no pueda borrar la tabla de producción.
• ▹Consistencia: si actualizo el nombre de un cliente, que se actualice en todas partes instantáneamente.
• ▹Durabilidad: si se va la luz mientras escribo datos, que no se pierdan.

Una base de datos resuelve TODO esto. Es software extremadamente sofisticado que ha evolucionado durante 50 años para garantizar estas propiedades. Las más importantes se conocen como ACID: Atomicidad (todo o nada), Consistencia (siempre estado válido), Isolation (cada transacción trabaja sin que las demás le cambien el suelo bajo los pies) y Durabilidad (lo guardado no se pierde). No necesitas memorizar esto ahora — lo vivirás en la práctica más adelante.

Un matiz sobre la "I", porque te va a pasar. "No se ven entre sí" es el ideal, y las bases de datos tienen varios niveles de cumplirlo. El que traen puestas de fábrica no es el más estricto: en PostgreSQL, una consulta lanzada dentro de una transacción sí ve lo que otras han confirmado mientras tanto. ¿Qué significa eso para ti? Que si lanzas el mismo informe dos veces en una tabla que está viva, puedes obtener dos números distintos sin haberte equivocado en nada. No es un error tuyo: es que entre una consulta y otra alguien guardó algo. Cuando un número tenga que ser exacto y reproducible — un cierre de mes, una cifra que se manda a dirección — lo que se hace es fijar el momento: filtrar por una fecha de corte, o pedirle a alguien de datos que te dé una foto congelada.

### Bases de datos relacionales: el estándar de 50 años

Las bases de datos relacionales organizan los datos en tablas con filas y columnas — exactamente como una hoja de cálculo, pero con superpoderes. Cada tabla tiene un esquema fijo (columnas definidas con tipos) y las tablas se pueden relacionar entre sí mediante claves (un campo que aparece en ambas tablas y las conecta).

Imagina una tienda online. Tienes una tabla de CLIENTES (id, nombre, email), una tabla de PRODUCTOS (id, nombre, precio, stock) y una tabla de PEDIDOS (id, cliente_id, producto_id, cantidad, fecha). El campo "cliente_id" en la tabla de pedidos APUNTA al "id" en la tabla de clientes. Así puedes preguntar: "dame todos los pedidos del cliente con email ana@tienda.com" cruzando ambas tablas. Eso es una relación — y de ahí viene el nombre "relacional".

1# Tres tablas. Las dos primeras tienen su id propio (clave primaria).
2clientes = [{"id": 1, "nombre": "Ana"}]
3productos = [{"id": 7, "nombre": "Teclado", "precio": 49.9}]
4
5# La tercera las RELACIONA guardando sus ids (claves ajenas)
6pedidos = [{"id": 100, "cliente_id": 1, "producto_id": 7}]
7
8# "Que compro Ana?" se responde saltando de tabla en tabla por el id
9pedido = pedidos[0]
10producto = [p for p in productos if p["id"] == pedido["producto_id"]][0]
11print(producto["nombre"])       # Teclado

Las bases de datos relacionales más conocidas son PostgreSQL (open-source, muy popular en startups y empresas), MySQL (también open-source, muy popular en web), Oracle (la corporativa por excelencia, carísima) y SQL Server (de Microsoft). Todas usan SQL como lenguaje para consultar y manipular los datos. SQL es exactamente lo que aprenderás a continuación: un idioma que llevan hablando las bases de datos más de 50 años.

### Bases de datos NoSQL: cuando las tablas no son suficientes

Relacional no es la única opción. En los años 2000, con la explosión de internet, surgieron necesidades que las bases de datos relacionales manejaban con dificultad: almacenar documentos con estructura variable (como perfiles de usuario donde cada uno tiene campos diferentes), manejar millones de lecturas por segundo (como un feed de red social) o almacenar relaciones complejas (como "amigos de amigos de amigos"). Así nacieron las bases de datos NoSQL — "No Solo SQL".

• ▹Documentos (MongoDB, CouchDB): almacenan documentos JSON. Cada documento puede tener estructura diferente. Ideal para catálogos con atributos variables.
• ▹Clave-valor (Redis, DynamoDB): como un diccionario gigante. Ultra rápidas para lecturas simples. Ideal para caché y sesiones.
• ▹Columnar (Cassandra, HBase): optimizadas para escribir y leer enormes cantidades de datos distribuidos. Ideal para series temporales y logs.
• ▹Grafos (Neo4j): almacenan nodos y relaciones. Ideales para redes sociales, recomendaciones, detección de fraude.

### Relacional vs NoSQL: no es una competencia

El error más común es pensar que tienes que elegir. La realidad es que la mayoría de empresas usan AMBOS: una base relacional para los datos transaccionales del negocio (clientes, pedidos, facturas — donde la consistencia es crítica) y una o varias NoSQL para casos específicos (caché en Redis para velocidad, MongoDB para un catálogo con atributos variables, etc.). Son herramientas complementarias, no competidoras.

### La base de datos como servidor: el modelo cliente-servidor

A diferencia de un archivo (que simplemente está en tu disco), una base de datos es un PROGRAMA que está corriendo constantemente, esperando peticiones. Es como un restaurante: el cocinero (la base de datos) está siempre listo en la cocina, y los camareros (tu código Python, la app web, etc.) le pasan comandas. Tú (cliente) envías una petición ("dame los pedidos de enero"), la base de datos la procesa y te devuelve el resultado. Este modelo permite que 1000 clientes pregunten al mismo tiempo sin problema.

En este curso practicarás SQL directamente en el navegador con DuckDB, que es una base de datos ligera diseñada para análisis. Pero conceptualmente, ya entiendes la idea: una base de datos es un programa especializado en gestionar datos, no un archivo pasivo. Las empresas usan servidores de bases de datos (PostgreSQL, MySQL, etc.) que están encendidos 24/7 atendiendo consultas.

### Resumen y preview

1. 01.Una base de datos es un programa especializado en almacenar y servir datos con garantías (concurrencia, seguridad, velocidad).
2. 02.Los archivos son para procesamiento en lote; las bases de datos son para acceso en tiempo real por múltiples usuarios.
3. 03.Relacional (PostgreSQL, MySQL): tablas con esquema fijo, relaciones por claves, SQL. El estándar.
4. 04.NoSQL (MongoDB, Redis, Cassandra): formatos flexibles para casos específicos. Complementa a relacional.
5. 05.SQL es el lenguaje que se usa para interactuar con bases de datos relacionales — lo aprenderás en profundidad en el siguiente módulo.