Capítulo 1 — ¿Por qué existen las bases de datos?

Una libreta que se queda pequeña

Imagina que acabas de crear tu propio juego de cartas, Kriaturas, y que el primer día se apuntan diez amigos. Anotas sus nombres en una libreta. Fácil.

Al mes siguiente sois quinientos. Y cada jugador tiene cartas, mazos, partidas ganadas y perdidas, amigos dentro del juego… La libreta ya no da más de sí. Si alguien te pregunta "¿quién tiene la carta más rara?", tardas media hora en encontrarlo. Y como lo apuntas todo a mano, un día escribes dos veces al mismo jugador con el nombre algo distinto y ya no sabes cuál es el bueno.

Ese caos tiene solución, y se llama base de datos. No es más que una forma ordenada de guardar información para poder encontrarla, cruzarla y mantenerla sin que se te vaya de las manos. En este libro vas a construir, poco a poco, la base de datos de Kriaturas. Y al hacerlo vas a aprender cómo se diseñan las bases de datos de verdad: las que hay detrás de cualquier juego, app o web que usas a diario.

No hace falta que sepas programar para seguir el libro. Pero si estás aprendiendo a programar al mismo tiempo, mejor todavía: lo que leas aquí encaja como una pieza más de ese rompecabezas.

El dato y la información no son lo mismo

Antes de seguir, conviene distinguir dos palabras que solemos usar como si fueran iguales: dato e información. Parecen lo mismo, pero no lo son, y la diferencia es el corazón de todo lo que viene después.

Mira este valor suelto:

1500

¿Qué es? Ni idea. Es solo un número. Eso es un dato: un valor en bruto, sin contexto. Por sí solo no dice nada.

Ahora lee esto:

DragoFuego99 tiene 1500 puntos de experiencia.

Ese mismo 1500, puesto en su sitio, ya significa algo: te dice cuánta experiencia lleva acumulada un jugador concreto. Eso es información: el dato interpretado, colocado en un contexto que lo hace útil.

La idea es sencilla, pero tiene cola. Una base de datos guarda datos (1500, DragoFuego99, 2026-03-01), y su gran trabajo es guardarlos de forma que tú puedas sacar información de ellos cuando la necesites: el ranking, las cartas de un jugador, quién ganó la última partida. Guardar el dato es fácil. Guardarlo de manera que luego puedas preguntarle cosas es lo difícil, y es justo para lo que existen las bases de datos.

🎮 ¿Por qué importa?

Apaga el juego un momento. Mentalmente, claro. ¿Dónde están ahora los nombres de tus jugadores, sus cartas, sus partidas? Si solo viven en la memoria del programa mientras está encendido, al apagarse desaparecen. Mañana nadie recuerda quién ganó, cuántas cartas tenía cada quien ni en qué nivel iba.

Un juego sin base de datos es un juego con amnesia: empieza de cero cada vez que arranca. La base de datos es la memoria que no se borra al apagar. Por eso es de las primeras cosas que necesitas cuando un juego deja de ser un experimento de una tarde y empieza a tener gente de verdad jugando.

Por qué la libreta (y la hoja de cálculo) se quedan cortas

Quizá estés pensando: "vale, pero yo apunto todo en una hoja de cálculo y me apaño". Y al principio es verdad. Una hoja de cálculo es un primer paso muy razonable. El problema aparece cuando el juego crece. Entonces se topa con tres muros.

Cuesta encontrar las cosas. Con cincuenta jugadores, buscas a mano y listo. Con cincuenta mil, necesitas que el programa te diga en un instante "dame todos los jugadores de nivel 20 que tienen la carta Burbujo". Una hoja de cálculo no está pensada para responder a esa clase de preguntas cruzadas.

Los datos se repiten. Si en cada partida vuelves a escribir el nombre completo del jugador, su correo y su país, acabas con la misma información copiada mil veces. A eso se le llama redundancia: el mismo dato repetido una y otra vez. Ocupa espacio y, sobre todo, es una trampa para el siguiente problema.

Los datos se contradicen. Si un jugador cambia de correo y tú lo tienes escrito en cien sitios, vas a corregir noventa y nueve y olvidar uno. A partir de ahí, tu hoja afirma dos cosas distintas sobre la misma persona. Eso es incoherencia: que tus datos se peleen entre ellos. Y cuando no puedes fiarte de tus propios datos, los datos dejan de servir.

Una base de datos está diseñada justo para esquivar estos tres muros: encuentra rápido, evita repetir y mantiene todo coherente. No por arte de magia, sino porque hay un programa especializado encargándose de ello. Ese programa tiene nombre.

⚠️ Errores comunes

"Con una hoja de cálculo me basta." A veces sí. Si lo tuyo es una lista de veinte cartas que no cambia, una hoja de cálculo es perfecta y montar una base de datos sería matar moscas a cañonazos. La hoja se queda corta cuando aparecen varias de estas señales a la vez:

• Tienes varias listas que se relacionan entre sí (jugadores y sus cartas y sus partidas), y necesitas cruzarlas.
• Los mismos datos se repiten en muchos sitios y mantenerlos al día se vuelve un infierno.
• Varias personas tocan los datos a la vez y se pisan unas a otras.
• Necesitas buscar y filtrar rápido entre muchísimos registros.

Si te suena a tu caso, no fuerces la hoja de cálculo: es la señal de que ha llegado el momento de una base de datos.

El portero de los datos: el SGBD

Cuando hablamos de "una base de datos", en realidad hay dos cosas distintas en juego, y conviene no confundirlas.

Una es la base de datos propiamente dicha: tus datos, guardados y ordenados. Los jugadores de Kriaturas, sus cartas, sus partidas.

La otra es el programa que se ocupa de todo ese trabajo: guardar los datos, buscarlos cuando se los pides, protegerlos para que no se pierdan ni se mezclen. Ese programa se llama Sistema Gestor de Bases de Datos, o SGBD para abreviar (en inglés lo encontrarás como DBMS, DataBase Management System).

Piénsalo así: la base de datos es el almacén; el SGBD es la persona que lo gestiona. Tú no entras al almacén a rebuscar entre las cajas. Le pides al gestor "tráeme las cartas raras de DragoFuego99" y él se encarga de ir, buscar y traértelas en orden.

Seguro que has oído algunos nombres de SGBD aunque no supieras qué eran: MySQL, PostgreSQL, SQLite, SQL Server… Son programas distintos, de empresas y comunidades distintas, pero todos hacen el mismo trabajo de fondo. A lo largo del libro vas a aprender a hablar con cualquiera de ellos, porque comparten un idioma común que verás en el próximo capítulo.

¿Y qué ganas exactamente al poner un SGBD a cuidar de tus datos, en lugar de una libreta o una hoja? Cuatro cosas, que iremos desarrollando a su tiempo:

• Evita repeticiones. Cada dato vive en un solo sitio, así que no se contradice consigo mismo.
• Mantiene los datos correctos. Puede impedir que entren disparates, como un jugador sin nombre o una carta con coste negativo. A esto se le llama integridad, y tiene un capítulo entero más adelante.
• Deja jugar a mucha gente a la vez. Mil personas pueden estar abriendo sobres y echando partidas al mismo tiempo sin que los datos se mezclen. Es la concurrencia.
• Protege los datos. Controla quién puede ver y cambiar qué, y procura que nada se pierda si algo va mal. Es la seguridad.

No te preocupes por estos cuatro términos ahora. Solo quédate con la idea: un SGBD no es solo "un sitio donde guardar cosas", es un guardián que trabaja por ti.

Casi cualquier videojuego lleva una base de datos detrás

Aquí va algo que conviene que tengas claro desde el principio: casi cualquier videojuego necesita una base de datos detrás. ¿Dónde se guardan tus jugadores, sus cartas, sus partidas, sus rankings? En una base de datos. Si algún día programas un juego, te vas a topar con una sí o sí.

No hace falta que sea un juego enorme. Piensa en lo más básico que pides hoy a cualquier juego con cuenta: que recuerde tu progreso cuando vuelves al día siguiente, que tenga un ranking, que te deje añadir amigos, que guarde tu colección. Cada una de esas cosas es, por dentro, una pregunta a una base de datos.

Kriaturas no es distinto. A lo largo del libro le vas a ir dando memoria pieza a pieza: primero quiénes son los jugadores y qué cartas existen; luego quién posee qué; luego los mazos, las partidas, los amigos, los intercambios. Cada capítulo añade un trozo de esa memoria, y al final tendrás el diseño completo de la base de datos de un juego de cartas de verdad.

"¿Y no me lo hace la IA?"

Es una pregunta justa, y la respuesta honesta es: sí, en parte. Hoy le pides a una IA "móntame la base de datos de un juego de cartas" y te suelta algo en segundos. Los frameworks modernos —las herramientas con las que se programa— también pueden generarla casi solos a partir de las clases de tu código.

Y aun así vas a tener que lidiar con ella. Porque generar la base de datos es el principio, no el final. Después toca:

• Entender lo que te han generado, para saber si está bien o tiene fallos escondidos.
• Consultarla, para sacar el ranking, las estadísticas, lo que el juego necesite mostrar.
• Arreglarla cuando algo se rompa, y algo se rompe siempre.
• Rediseñarla cuando el juego crezca y aparezcan cosas que nadie había previsto.

Para todo eso necesitas entender los fundamentos. Una IA te da una respuesta; entender los fundamentos te permite saber si esa respuesta es buena, mejorarla y construir sobre ella. Eso es lo que separa a quien usa una herramienta de quien sabe construir. Y es justo lo que este libro quiere darte.

Una idea para sacarle el máximo partido: este libro acompaña de maravilla a quien está aprendiendo a programar. Mientras un curso te enseña a crear el juego, aquí aprendes a darle la memoria que necesita para no olvidar nada.

Lo que llevas hasta aquí

Antes de pasar a la práctica, recapitulemos en una frase: una base de datos es una forma ordenada de guardar datos para poder sacar información de ellos sin que el caos te gane, y un SGBD es el programa que hace ese trabajo por ti, evitando que los datos se repitan, se contradigan o se pierdan.

Todavía no hemos guardado nada de verdad. Sabemos qué queremos (una memoria ordenada para Kriaturas) y por qué (porque la libreta no escala). Falta lo más interesante: ¿y cómo se guarda todo esto en orden? La respuesta tiene forma de rejilla con filas y columnas, y se llama tabla. Es lo primero que vas a construir en el próximo capítulo.