Bases de datos

Podrías guardar todos los datos de tu aplicación en archivos de texto y, para algo chico, bastaría. Pero en cuanto necesitas buscar, relacionar, actualizar de forma segura o servir a varios usuarios a la vez, los archivos se vuelven un infierno. Las bases de datos existen para resolver exactamente eso: guardar grandes volúmenes de datos y responder consultas de forma rápida, confiable y concurrente. Esta ficha explica como lo logran y que concesiones esconden los modelos que no son el clásico.

El modelo relacional y por qué ganó

La idea fundacional del modelo relacional es de organización matemática: los datos viven en tablas de filas y columnas, y las relaciones entre tablas se expresan con claves. Una clave primaria identifica cada fila de una tabla; una clave foránea en otra tabla apunta hacia ella. Así, un cliente y sus pedidos son dos tablas vinculadas, no dos listas sueltas que alguien debe mantener a mano.

Esa estructura tiene una virtud decisiva: separa el como se guardan los datos del que quieres preguntar. Tu describes la consulta; el motor decide la forma más eficiente de resolverla. Sobre ese modelo se construyó SQL, el lenguaje de consultas que lleva décadas como lengua franca de los datos, y buena parte del éxito de las bases relacionales viene de haber estandarizado esa forma de preguntar.

Normalización: evitar la redundancia

Si guardas la dirección de un cliente en cada uno de sus pedidos, la tienes repetida docenas de veces, y cuando se muda hay que actualizarlas todas, con el riesgo de dejar alguna antigua. La normalización es el conjunto de reglas que evita ese desastre: organiza las tablas para que cada dato viva en un solo lugar, eliminando redundancia y contradicciones.

Como toda decisión, tiene un costo. Una base muy normalizada puede obligar a recomponer una respuesta juntando muchas tablas, lo que es costoso. Por eso a veces se desnormaliza a propósito, duplicando datos a cambio de lecturas más rápidas, sobre todo en sistemas que se leen muchísimo más de lo que se escriben. No hay una respuesta universal: es un equilibrio entre consistencia y velocidad.

Índices: de tres segundos a tres milisegundos

Sin ayuda, buscar algo en una tabla de millones de filas obliga a revisarlas una por una. Un índice es, en esencia, lo mismo que el índice de un libro: una estructura auxiliar que permite encontrar las filas que cumplen una condición sin recorrerlas todas. Agregar el índice correcto puede hacer que una consulta pase de tres segundos a tres milisegundos.

Los índices no son gratis. Ocupan espacio y deben mantenerse actualizados cada vez que se inserta o modifica un dato, lo que encarece las escrituras. Por eso se eligen con criterio: se indexa lo que se consulta a menudo, no todo. El trabajo de quien diseña una base incluye, precisamente, anticipar las consultas y preparar los índices para ellas.

Transacciones y ACID

Imagina que transfieres dinero de una cuenta a otra: hay que restar de una y sumar a la otra. Si el sistema cae entre medio, el dinero desaparece. La transacción es el mecanismo que evita eso: agrupa varias operaciones en una unidad que o se completa entera o no se hace nada, nunca a medias.

A las propiedades que debe cumplir una transacción se les llama ACID. Atomicidad: todo o nada. Consistencia: la base pasa de un estado valido a otro valido. Aislamiento: transacciones concurrentes no se entrometen entre si, como si cada una fuera la única. Durabilidad: una vez confirmada, el cambio sobrevive a un apagón. Lograr esto, sobre todo el aislamiento cuando muchos usuarios escriben a la vez, es uno de los problemas más finos de las bases de datos, y se resuelve con bloqueos, con versiones múltiples o con distintos niveles de aislamiento según el equilibrio entre seguridad y velocidad que se busque.

NoSQL y el trade-off

No todos los datos encajan bien en tablas relacionales, y no todas las aplicaciones necesitan la promesa estricta de ACID. De ahí surgieron las bases NoSQL, una familia heterogénea: las documentales, que guardan registros flexibles parecidos a objetos; las de clave-valor, ultrarrápidas para lo más sencillo; las de columnas, pensadas para volúmenes enormes; y las de grafos, para cuando lo importante son las relaciones.

Todas resuelven un problema real, pero ninguna regala nada. A cambio de escalar mejor o de modelar ciertos datos con más naturalidad, suelen ceder algo de consistencia inmediata: en sistemas distribuidos grandes, los cambios pueden tardar en verse en todas las copias, lo que se llama consistencia eventual. El trade-off fundamental está recogido en el teorema CAP, que dice, en pocas palabras, que ante una falla de red un sistema distribuido debe elegir entre consistencia y disponibilidad: no puede garantizar ambas a la vez. Conocer esa elección, y saber en que lado está tu base, es parte de usarla bien.

Lo esencial

Una base de datos no es un lugar donde guardar archivos, sino un sistema que garantiza buscar rápido, mantener la coherencia y soportar el caos de muchos usuarios escribiendo a la vez. El modelo relacional, con sus tablas, claves y SQL, sigue siendo el punto de partida por su solidez. Los índices son lo que separa una consulta lenta de una veloz, y las transacciones ACID lo que separa un dato confiable de un desastre. Y cuando el problema se sale del molde relacional (escala extrema, datos flexibles, relaciones densas), las bases NoSQL ofrecen alternativas, siempre a cambio de alguna concesión que conviene tener consciente. Elegir base de datos es, en el fondo, elegir que promesas necesitas que se cumplan.