Qué es una relación entre tablas (con ejemplo real)

Una relación entre tablas es un enlace: en lugar de escribir el dato otra vez, lo apuntas donde ya vive.

Tienes una tabla de clientes y otra de pedidos. Cada pedido no guarda el nombre del cliente escrito. Guarda un enlace al cliente que está en la otra tabla.

Ese cambio, que parece cosmético, es lo que separa una lista que se te pudre en tres meses de un sistema que aguanta años.

¿Qué es una relación entre dos tablas?

Vamos con el ejemplo, porque explicado en abstracto no se entiende y explicado con pedidos se entiende en treinta segundos.

Sin relaciones, tendrías una sola tabla así:

Mira la tercera fila. El correo está mal escrito. Ha pasado porque alguien lo volvió a teclear.

Y ahora imagina que Marta se muda a Wrocław. Tienes que cambiarlo en las tres filas. Si tiene cuarenta pedidos, en cuarenta. Y el día que te dejes uno, tendrás una clienta que vive en dos sitios a la vez según qué pedido mires.

Con relaciones, lo partes en dos:

La columna "Cliente" de la segunda tabla ya no es texto. Es un enlace a una fila de la primera.

Cambias la ciudad en un sitio y cambia en todos los pedidos. Escribes el correo una vez y no hay forma de que aparezca mal en la fila 1003. El dato vive en un solo lugar.

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

Porque el problema no es el espacio que ahorras. Es que el dato repetido siempre acaba divergiendo.

Siempre. No es cuestión de ser ordenado. Con dos personas metiendo datos y seis meses de uso, vas a tener "Marta Ruiz", "marta ruiz" y "M. Ruiz" en la misma columna. Y el día que filtres por cliente, te van a salir tres personas donde hay una.

He visto hojas de cálculo enteras inservibles por esto. No porque faltaran datos, sino porque el mismo cliente estaba escrito de cinco maneras y ya no había forma de contar cuántos pedidos tenía nadie.

Con una relación eso no puede pasar, porque no estás escribiendo el nombre. Estás señalando una fila.

Los tres tipos de relación que existen

Se les ponen nombres raros pero son tres ideas muy sencillas.

Uno a muchos. La más común con diferencia. Un cliente tiene muchos pedidos, pero cada pedido es de un solo cliente. Un vídeo tiene muchos comentarios, cada comentario es de un vídeo. El 80% de lo que vas a montar es esto.

Muchos a muchos. Un proyecto tiene varias personas y cada persona está en varios proyectos. Aquí no vale con un enlace en un lado: hace falta una tabla en medio que apunte a las dos. Suena a complicación innecesaria hasta que intentas hacerlo sin ella.

Uno a uno. Cada fila de aquí se corresponde con una sola de allí. Se usa poco, y casi siempre para separar datos sensibles del resto o información que solo tiene la mitad de las filas.

Si sabes reconocer cuál de las tres tienes delante, ya sabes diseñar una base de datos decente. En serio, es casi todo.

La pregunta que resuelve el diseño

Cuando dudo entre meter algo como columna o como tabla aparte, uso una sola pregunta:

¿Esto lo voy a escribir más de una vez?

Si la respuesta es sí, va en su propia tabla y lo enlazas.

Ejemplo tonto pero real: si tienes una columna de "estado" con cinco valores posibles que se repiten en mil filas, eso no necesita una tabla, necesita un desplegable, que es la versión ligera de lo mismo. Si tienes una columna de "proveedor" con datos del proveedor detrás (teléfono, dirección, condiciones), eso sí necesita tabla propia.

La otra pregunta útil: ¿esta cosa tiene información propia? Un cliente tiene correo, ciudad y teléfono. Un estado como "Pendiente" no tiene nada detrás. El primero es una tabla, el segundo es un valor.

Lo que una relación no es

No es una fórmula de búsqueda. En una hoja de cálculo puedes simular esto con funciones de búsqueda, y funciona, hasta que alguien inserta una fila en medio o cambia el orden. Entonces se rompe en silencio y te enteras semanas después. Una relación de verdad no se rompe al reordenar.

No es duplicar la tabla. Enlazar no es copiar. La información sigue en un solo sitio y la otra tabla la está mirando.

No hace la base más lenta. Al contrario. Buscar en una tabla de mil clientes es más rápido que buscar en una de cincuenta mil filas donde el cliente aparece repetido.

No es cosa de programadores. Herramientas como Airtable te dejan crear relaciones eligiendo un tipo de columna. Cero código. El paso a paso con capturas está en el tutorial de relaciones en Airtable.

Lo que ganas el día que las tienes montadas

Esto es lo que no se ve hasta que lo tienes delante.

Puedes contar cosas. Cuántos pedidos tiene cada cliente, cuánto se ha gastado en total, cuándo fue el último. Todo eso sale solo cuando la relación existe, y es imposible cuando el nombre está escrito de tres formas distintas.

Puedes ver desde los dos lados. Abres la ficha de Marta y ves sus tres pedidos. Abres el pedido 1002 y ves la ficha entera de Marta. Es el mismo enlace mirado desde cada extremo, no hay que montar nada más.

Puedes cambiar sin miedo. Corriges un dato en un sitio y se corrige en todas partes. Eso quita una capa de ansiedad que la gente que trabaja con hojas de cálculo lleva encima sin darse cuenta.

Puedes montar cosas encima. Una web que lea de ahí, un panel para el equipo, una automatización que mande un correo a los clientes que llevan tres meses sin pedir. Ninguna de esas cosas se puede montar de forma fiable sobre una tabla con datos repetidos.

El error que más caro sale

Empezar con una sola tabla "porque de momento es poca cosa" y añadir columnas según hacen falta.

Acabas con una tabla de cuarenta columnas donde la mitad están vacías en la mitad de las filas, porque hay columnas que solo aplican a algunos casos. Y llega un momento en que no puedes contestar preguntas básicas del tipo "cuántos clientes tengo", porque cada cliente aparece tantas veces como pedidos ha hecho.

Migrar eso después es un dolor. No es imposible, se hace, pero se te va un fin de semana y algún dato se pierde por el camino.

Media hora al principio dibujando en un papel qué tablas hay y cómo se enlazan te ahorra ese fin de semana. Es la media hora mejor invertida de todo el proyecto y es justo la que todo el mundo se salta.

Si quieres el concepto completo de por qué las bases de datos funcionan así, lo tengo en qué es una base de datos relacional. Y si lo que buscas es montar algo ya, el mapa de herramientas está en bases de datos y CRM sin código.

Si no tienes claro cómo estructurar la información de tu negocio ni con qué herramienta, tengo un test corto que te orienta en dos minutos.

Hacer el test de IA