Bases de datos relacionales

Hay una tecnología que cumple medio siglo y sigue siendo la primera opción para guardar datos serios en casi cualquier empresa del mundo. No es una red neuronal ni una cadena de bloques: es la base de datos relacional, la humilde tabla con filas y columnas que Edgar Codd propuso en 1970. Que haya sobrevivido a tantas modas dice algo sobre lo bien pensada que estaba.

La idea, en una servilleta

Todo se reduce a tablas. Cada tabla describe un tipo de cosa: una de clientes, otra de pedidos, otra de productos. Dentro de la tabla, cada fila es una cosa concreta (un cliente) y cada columna un atributo (su nombre, su correo, su ciudad).

Lo interesante no es la tabla sola, sino cómo se relacionan entre sí. Y ahí entran dos piezas clave:

• La clave primaria (primary key): una columna que identifica cada fila sin ambigüedad. El id del cliente, su RUT. Única, nunca vacía.
• La clave foránea (foreign key): una columna que apunta a la clave primaria de otra tabla. Así la tabla pedidos guarda un cliente_id que remite al cliente que hizo el pedido.

No repetir: la obsesión sana de la normalización

¿Por qué separar clientes y pedidos en dos tablas, en lugar de guardar el nombre del cliente en cada pedido? Porque repetir información es la fuente de casi todos los errores.

Si Ana cambia de correo y su dato estaba copiado en cincuenta pedidos, tendrías que actualizar cincuenta filas y basta que se te escape una para que la base quede inconsistente. Guardándolo una sola vez, en la tabla de clientes, lo cambias en un lugar y listo.

Ese principio —cada dato vive en un solo sitio— se llama normalización. En la práctica significa partir los datos en tablas hasta que ninguna columna dependa de algo que no sea la clave. No es dogma: a veces se desnormaliza a propósito para ganar velocidad de lectura. Pero conviene saber la regla antes de romperla.

El pacto que nunca se rompe: ACID

Lo que distingue a una base de datos relacional de una simple planilla es una promesa formal sobre las transacciones —grupos de operaciones que deben ocurrir como un todo. Se resume en cuatro letras, ACID:

• Atomicidad — todo o nada. Si transfieres dinero de una cuenta a otra, o se descuenta y se abona, o no pasa nada. Nunca a medias.
• Consistencia — la base siempre queda en un estado válido, respetando sus reglas.
• Aislamiento — dos operaciones simultáneas no se pisan; cada una ve la base como si estuviera sola.
• Durabilidad — una vez confirmado, queda grabado aunque se corte la luz un segundo después.

Ese contrato es la razón por la que un banco confía sus saldos a PostgreSQL y no a un archivo de texto. Cuando el dato no puede estar mal, se elige relacional.

Qué motor elegir

Todos hablan SQL, el idioma que veremos en la próxima lección, así que cambiar entre ellos es más fácil de lo que parece:

• PostgreSQL — el favorito open source de la última década. Robusto, extensible (incluso guarda vectores, ya lo veremos), la opción por defecto para empezar hoy.
• MySQL / MariaDB — enorme presencia histórica, sobre todo en la web.
• SQLite — una base entera en un solo archivo, sin servidor. Perfecta para prototipos, apps móviles y para aprender. De hecho, este mismo sitio guarda sus lecciones en SQLite.
• SQL Server / Oracle — los pesos pesados del mundo corporativo.

En resumen

Una base de datos relacional organiza la información en tablas enlazadas por claves, evita repetir datos mediante la normalización y garantiza que nada se corrompa gracias a las propiedades ACID. Es la respuesta correcta para la enorme mayoría de los datos estructurados de una organización. Ahora que sabemos cómo están guardados, falta lo mejor: aprender a preguntarles cosas. Ese es el trabajo de SQL.