KriaturasBases de datos para quien empieza

Parte I · Primeros pasos

Capítulo 2 — Tu primera tabla

Al acabar este capítulo sabrás: qué son una entidad, un atributo y un valor; cómo se organiza la información en una tabla de filas y columnas; por qué cada tabla necesita una clave primaria; qué es un tipo de dato; y cómo crear tus primeras tablas y meterles datos con SQL. Aquí empieza el cómo: vas a escribir tus primeras órdenes y a poner el primer ladrillo de Kriaturas.


De la idea a la tabla

Piensa en un jugador de Kriaturas. ¿Qué datos te interesan? El nombre dentro del juego, el correo, el día en que se registró… Son datos que describen a una cosa: el jugador.

A esa "cosa" sobre la que quieres guardar información se le llama entidad. Suena técnico, pero es de lo más natural: en Kriaturas las entidades son las cosas que te importan del juego. El jugador, la carta, el mazo, la partida. De momento nos quedamos con la primera, el jugador.

Cada cosa que sabes de una entidad es un atributo. Del jugador nos interesan, por ahora, tres: su alias (el nombre con el que juega), su email y su fecha de alta. Y cada atributo, en un jugador concreto, tiene un valor: el alias de uno de ellos podría ser DragoFuego99.

Y aquí está la idea que lo sostiene todo. Esa información se guarda en una tabla: una rejilla de filas y columnas, parecida a una hoja de cálculo, pero con reglas.

  • Cada columna es un atributo (alias, email, fecha de alta).
  • Cada fila es un jugador concreto, con sus valores.
alias email fecha_alta
DragoFuego99 drago@ejemplo.com 2026-03-01
LunaVerde luna@ejemplo.com 2026-03-04

Y ya está: una tabla por entidad, una columna por atributo, una fila por cada caso real. Esa regla de tres te va a acompañar el resto del libro. Pero falta un detalle sin el que todo esto se viene abajo, y es más importante de lo que parece.

La pregunta del millón: ¿cómo distingo dos jugadores?

Imagina que dos jugadores eligen el mismo alias, LunaVerde. Si alguien te pide "bórrame a LunaVerde", ¿a cuál borras? Necesitas algo que identifique a cada fila sin ninguna duda.

Ese algo es la clave primaria: un atributo (o varios) cuyo valor es único para cada fila y nunca se repite. Lo más habitual es añadir una columna id, un número distinto para cada jugador que la propia base de datos va asignando.

id alias email fecha_alta
1 DragoFuego99 drago@ejemplo.com 2026-03-01
2 LunaVerde luna@ejemplo.com 2026-03-04

Ahora, aunque haya dos LunaVerde, cada uno tiene un id distinto. Cero ambigüedad. Con esto ya tienes el modelo en la cabeza; toca dárselo a la base de datos en su propio idioma.

¿Por qué un número y no, por ejemplo, el email (que también es único)? Porque un número pequeño es cómodo: ocupa poco, nunca cambia y es fácil de referenciar desde otras tablas. Más adelante, cuando un jugador tenga mazos y partidas, esos mazos y partidas apuntarán al jugador justo por ese id. Lo verás en el capítulo 4. Por ahora quédate con la idea: cada fila, su identificador único.

Elegir el tipo de cada dato

Antes de teclear la orden, falta una decisión: qué clase de valor admite cada columna. No es lo mismo guardar un número que un texto o una fecha. A esa clase se le llama tipo de dato, y se elige columna por columna.

¿Por qué importa? Porque la base de datos trata cada tipo de forma distinta. Si le dices que el coste de una carta es un número, podrá sumarlo, ordenarlo de menor a mayor y comprobar que no metes letras por error. Si lo guardas como texto, pierdes todo eso.

Con estos tres tipos tienes de sobra para empezar:

  • INTEGER — números enteros. Para el id y para el coste de una carta.
  • VARCHAR(n) — texto de longitud variable, hasta n caracteres. Para el alias, el email o el nombre de una carta. (En el estándar se llama CHARACTER VARYING, pero en la práctica casi todo el mundo escribe VARCHAR, así que eso usamos.)
  • DATE — fechas. Para la fecha de alta.

Existen muchos más (DECIMAL para números con decimales, TIMESTAMP para fecha y hora juntas, y unos cuantos parientes), pero no los necesitas todavía. Los irás conociendo cuando un dato concreto los pida.

Creando la tabla de verdad

Para hablar con una base de datos se usa un lenguaje llamado SQL. Si ahora mismo te suena a chino, no pasa nada: nadie lo aprende leyéndolo, se aprende usándolo, y eso es lo que vas a hacer a partir de aquí. Tu primera orden crea la tabla de jugadores:

SQL
CREATE TABLE jugador (
    id         INTEGER       PRIMARY KEY,
    alias      VARCHAR(20),
    email      VARCHAR(100),
    fecha_alta DATE
);

Léelo despacio. Le estás diciendo a la base de datos: "crea una tabla que se llame jugador, con estas cuatro columnas; el id es la clave primaria". INTEGER, VARCHAR y DATE son los tipos de datos que acabas de ver: indican qué admite cada columna (un número entero, un texto de hasta 20 o 100 caracteres, una fecha).

Fíjate en la estructura, porque se repite siempre: la palabra CREATE TABLE, el nombre de la tabla, y entre paréntesis la lista de columnas; cada columna lleva su nombre y su tipo, separadas por comas. Al final, marcamos cuál es la clave primaria.

La tabla está creada, pero vacía. Vamos a meter el primer jugador con la orden INSERT:

SQL
INSERT INTO jugador (id, alias, email, fecha_alta)
VALUES (1, 'DragoFuego99', 'drago@ejemplo.com', '2026-03-01');

La orden se lee igual de fácil: "inserta en jugador, en estas columnas, estos valores". El orden de los valores tiene que coincidir con el orden de las columnas que has nombrado. Y un detalle importante: el texto y las fechas van entre comillas simples ('DragoFuego99'), mientras que los números van sueltos (1). Es una de esas cosas que se olvidan al principio y la base de datos te lo recuerda con un error.

Y ya está: tu base de datos de Kriaturas tiene su primer jugador dentro. Puedes añadir el resto del reparto repitiendo la orden:

SQL
INSERT INTO jugador (id, alias, email, fecha_alta)
VALUES (2, 'LunaVerde', 'luna@ejemplo.com', '2026-03-04');

INSERT INTO jugador (id, alias, email, fecha_alta)
VALUES (3, 'PixelPunk', 'pixel@ejemplo.com', '2026-03-10');

INSERT INTO jugador (id, alias, email, fecha_alta)
VALUES (4, 'ToxiRana', 'toxi@ejemplo.com', '2026-03-15');

Después de estas órdenes, la tabla jugador se ve así por dentro:

id alias email fecha_alta
1 DragoFuego99 drago@ejemplo.com 2026-03-01
2 LunaVerde luna@ejemplo.com 2026-03-04
3 PixelPunk pixel@ejemplo.com 2026-03-10
4 ToxiRana toxi@ejemplo.com 2026-03-15

Para que veas el alcance de lo que acabas de hacer: crear una tabla y meterle una fila es, ni más ni menos, lo que ocurre por dentro cada vez que te registras en una app. Lo has escrito tú, con unas pocas líneas. Y esto es justo lo que querría decir lo de "casi cualquier videojuego necesita una base de datos detrás": el momento en que alguien crea una cuenta en tu juego es un INSERT en una tabla como esta. Ahora hagámoslo con las cartas, que sin ellas el juego no va a ninguna parte.

Resumen

Has dado el primer paso real: pasar de "datos sueltos" a datos ordenados. El camino, que vas a repetir una y otra vez, es siempre el mismo. Eliges la entidad (la cosa de la que guardas información), decides sus atributos (qué quieres saber de ella), le das una clave primaria (para no confundir unas filas con otras) y eliges el tipo de dato de cada columna. Después, CREATE TABLE para crear la rejilla e INSERT para llenarla. Con eso ya tienes las tablas jugador y carta de Kriaturas, con datos dentro.

Pero unas tablas con datos no sirven de mucho si no puedes preguntarles cosas. "¿Qué cartas cuestan 2 o menos?" "¿Quién se registró en marzo?" Ahora mismo, para responder, tendrías que mirar las tablas a ojo, justo el problema de la libreta del capítulo 1. En el próximo capítulo aprendes a hacerle preguntas a la base de datos y a que te conteste al instante.