Qué es una base de datos relacional en cristiano sin liarte

Una base de datos relacional es la que guarda la información en varias tablas separadas que se apuntan entre sí, en vez de meterlo todo en una sola tabla gigante.

Lo de "relacional" viene de eso: de las relaciones entre las tablas. No de que sea sociable.

El término sale en cada tutorial de backend y en cada página de precios de herramientas, y casi nunca se explica. Así que vamos con la libreta de un fontanero, que es el ejemplo con el que se entiende de golpe.

¿Qué significa base de datos relacional?

Imagina un fontanero que apunta sus trabajos en una libreta. Una línea por trabajo:

"12 de marzo, María García, calle Mayor 4, teléfono tal, cambiar grifo, 80 euros."

Funciona. Hasta que María le llama otras seis veces. Ahora tiene el nombre, la dirección y el teléfono de María escritos siete veces en la libreta. Y el día que María se muda, tiene que buscar y corregir siete líneas. Si se le pasa una, ya tiene dos direcciones distintas para la misma persona y no sabe cuál es la buena.

Eso es una tabla única, y es exactamente lo que le pasa a todo el mundo con su primera hoja de cálculo.

La versión relacional es otra cosa. Dos libretas.

En la primera, los clientes. María aparece una sola vez, con su dirección y su teléfono. Le pones un número, el 7.

En la segunda, los trabajos. Cada línea tiene la fecha, lo que hiciste, lo que cobraste, y el número 7 apuntando a María.

Ya está. Eso es una base de datos relacional. Cada cosa se guarda una vez, en el sitio que le corresponde, y las demás la señalan.

Por qué esto importa más de lo que parece

Cuando María se muda, cambias su dirección una vez. Los siete trabajos siguen apuntando al mismo número 7, así que todos quedan actualizados solos. No hay copias que corregir porque no hay copias.

Ese es el beneficio real y es enorme: la información vive en un solo sitio. Todo lo demás son consecuencias.

Puedes preguntar cosas que antes eran imposibles. Cuánto ha gastado María en total. Qué clientes no te llaman desde hace un año. Cuál es el trabajo que más repites. Con una tabla única eso son filtros manuales y dolores de cabeza. Con tablas relacionadas es una consulta.

Y puedes crecer sin que se te caiga encima. Añadir "presupuestos" o "facturas" es añadir otra tabla que apunta a las que ya tienes. No hay que rehacer nada.

Las tres palabras que vas a ver siempre

Tabla. Una hoja. Una para clientes, otra para trabajos. Cada tabla guarda un tipo de cosa y solo uno. Si tu tabla se llama "clientes y trabajos", ya has empezado mal.

Campo. Una columna. El nombre, el teléfono, la fecha. Cada campo tiene su tipo: texto, número, fecha, sí o no. Eso importa, porque si guardas fechas como texto no vas a poder ordenar por fecha y te vas a enterar tarde.

Relación. El hilo entre dos tablas. En las herramientas modernas se hace con un clic: eliges el campo, dices "esto enlaza con la tabla de clientes", y listo. Por debajo lo que hay es el número que apunta.

Las relaciones tienen tipos, y ahí es donde la gente se atasca de verdad. Un cliente puede tener muchos trabajos, pero cada trabajo es de un solo cliente. Eso es una relación de uno a muchos, y es la que vas a usar el noventa por ciento del tiempo. Lo desarrollo entero en el post de qué es una relación entre tablas.

Tres ejemplos con los que se ve claro

Una tienda. Tabla de productos, tabla de pedidos, tabla de clientes. Un pedido apunta a un cliente y a varios productos. Si cambias el nombre de un producto, cambia en todos los pedidos a la vez.

Un blog. Tabla de artículos, tabla de autores, tabla de categorías. El autor aparece una vez aunque haya escrito doscientos artículos.

Una escuela. Tabla de alumnos, tabla de cursos, tabla de matrículas. La tabla de en medio existe precisamente porque un alumno hace varios cursos y un curso tiene varios alumnos. Ese caso, el de muchos a muchos, siempre necesita una tabla intermedia. Cuando te choques con él, ya sabes qué falta.

¿Y las herramientas? ¿Cuál es relacional?

Casi todas las modernas lo son, con distintos niveles de seriedad.

Airtable y las herramientas parecidas te dan tablas con relaciones y una interfaz que parece una hoja de cálculo. Perfecto para empezar, porque ves lo que estás haciendo. El límite lo encuentras cuando tienes muchísimos registros o consultas complicadas.

Supabase y las bases de datos de verdad son otra liga. Más potentes, sin límite práctico de tamaño, pero te piden entender un poco más. A cambio, no te vas a quedar corto nunca.

Y luego está la hoja de cálculo de toda la vida, que no es relacional aunque puedas apañarlo con fórmulas de búsqueda. Se puede vivir así un tiempo, pero es un apaño y se nota.

La comparación entera, con cuándo saltar de una a otra, la tengo en el hub de bases de datos y CRM sin código.

El error que comete todo el mundo la primera vez

Meterlo todo en una tabla porque al principio parece más cómodo.

Y es que lo es. Con veinte filas, una sola tabla se maneja de maravilla y separar en dos parece una complicación innecesaria. El problema no aparece a las veinte filas, aparece a las quinientas, cuando ya llevas meses metiendo datos y rehacerlo significa migrar todo a mano.

La señal de alarma es fácil de detectar: si estás escribiendo el mismo texto en varias filas, esa columna quiere ser una tabla. El nombre del cliente repetido, la categoría repetida, el nombre del proveedor repetido. Cada repetición es una futura corrección a mano.

Cuando lo veas, para y separa. Cuesta media hora entonces y una tarde entera dentro de seis meses.

Lo que no es una base de datos relacional

No es una hoja de cálculo con pestañas. Tener varias pestañas no crea relaciones. Si estás copiando el nombre del cliente a mano en la pestaña de trabajos, sigues teniendo el problema de la libreta.

No es siempre la respuesta correcta. Si guardas cosas que no se relacionan entre sí (registros sueltos, documentos, textos), hay otros tipos de base de datos que encajan mejor. No todo el mundo necesita tablas.

No es difícil. El concepto se explica con un fontanero y una libreta. Lo difícil no es entenderlo, es decidir cómo partir tus datos en tablas la primera vez, y eso se aprende haciéndolo mal una vez.

No es para programadores. Puedes montar una base relacional decente sin escribir una línea de código. Lo que sí necesitas es pensar diez minutos antes de empezar a meter datos, que es el paso que todo el mundo se salta.

Cómo montar la tuya sin liarla

Escribe en un papel los tipos de cosa que vas a guardar. Clientes, trabajos, facturas, lo que sea. Cada tipo, una tabla. Si dudas de si algo es una tabla o un campo, pregúntate si tiene vida propia: un cliente la tiene, un teléfono no.

Después dibuja flechas entre las tablas y di la frase en voz alta: "un cliente tiene muchos trabajos". Esa frase es la relación, literalmente.

Y solo entonces abres la herramienta. Diez minutos de papel te ahorran una tarde de rehacerlo, te lo digo por experiencia.

Si tu caso es montar una app encima de esos datos, la continuación natural es qué es una base de datos en una app sin código.

Si no tienes claro si tu proyecto necesita una base de datos en condiciones o te sobra con una hoja de cálculo, el test de IA te da una lectura rápida de por dónde empezar.

Hacer el test de IA