Keys - Organizando datos
1. ¿Por qué necesitamos organización?
Si en una biblioteca los libros están mezclados al azar, para encontrar uno determinado tendrías que revisar cada estante, libro por libro. Sería un caos
Para posibilitar una búsqueda rápida podemos:
- asignar Un número único a cada libro (como un ISBN)
- Ficheros organizados por autor, tema, título
- Referencias cruzadas que te dicen en qué estante está cada libro
Eso es exactamente lo que hacen las keys e indexes en las bases de datos: organizan y aceleran la búsqueda de información.
2. Keys (Claves) - Los identificadores únicos
Una key es una columna (o conjunto de columnas) que tiene una función especial en la tabla: identificar registros de manera única o establecer relaciones.
¿Son obligatorias las keys?
Técnicamente no, pero prácticamente sí. Una tabla sin key es como una casa sin dirección: funciona, pero es muy difícil encontrarla o referenciarla. IMagina:
CREATE TABLE personas (
nombre VARCHAR(50),
edad INT
);
Si en nuestra tabla tenemos que modificar los datos de una persona, y hay varias que se llaman "Juan", ¿como identificamos cual hay que modificar?
3. Tipos de Keys
Primary Key (Clave Primaria) - El DNI de cada registro
La Primary Key es el identificador único y principal de cada registro en una tabla. Es como el DNI de una persona: único, obligatorio e inmutable.
Reglas estrictas:
- Única: No puede repetirse jamás
- No NULL: Siempre debe tener valor
- Inmutable: No debe cambiar una vez asignada
- Una por tabla: Solo puede haber una Primary Key por tabla
Ejemplo práctico:
DESC actor;
+-------------+----------------------+------+-----+-------------------+
| Field | Type | Null | Key | Default |
+-------------+----------------------+------+-----+-------------------+
| actor_id | smallint(5) unsigned | NO | PRI | NULL | ← Primary Key
| first_name | varchar(45) | NO | | NULL |
| last_name | varchar(45) | NO | MUL | NULL |
| last_update | timestamp | NO | | CURRENT_TIMESTAMP |
+-------------+----------------------+------+-----+-------------------+
¿Por qué actor_id
y no first_name
?
- Puede haber varios actores llamados "John Smith"
- Los nombres pueden cambiar (matrimonio, error de escritura)
- Los números son más eficientes para búsquedas
Tipos de Primary Keys:
1. Natural Key (Clave Natural)
Usa un valor que tiene significado en el mundo real.
-- Ejemplo: tabla de países
CREATE TABLE paises (
codigo_iso CHAR(2) PRIMARY KEY, -- 'ES', 'FR', 'US'
nombre VARCHAR(100)
);
Ventajas: Fácil de entender y recordar Desventajas: Puede cambiar (ej: códigos postales)
2. Surrogate Key (Clave Subrogada)
Usa un valor artificial sin significado en el mundo real.
-- Ejemplo: tabla de actores (más común)
CREATE TABLE actores (
actor_id INT AUTO_INCREMENT PRIMARY KEY, -- 1, 2, 3, 4...
nombre VARCHAR(100),
apellido VARCHAR(100)
);
Ventajas: Nunca cambia, muy eficiente Desventajas: No tiene significado para humanos
¿Cuándo usar cada tipo?
Usa Natural Key cuando:
- El valor natural es verdaderamente único y estable
- Ejemplo: código de país ISO, número de seguridad social
Usa Surrogate Key cuando:
- No hay un identificador natural claro
- El identificador natural puede cambiar
- Necesitas máximo rendimiento
- Recomendación: En la mayoría de casos, usa Surrogate Keys
Foreign Key (Clave Foránea) - Las referencias
Una Foreign Key es una columna que apunta a la Primary Key de otra tabla. Es como una "referencia bibliográfica" que conecta tablas.
Imagina que en un trabajo citas un libro. En lugar de copiar todo el libro en tu ensayo, escribes: "Ver: García, M. (2020), página 45". La Foreign Key funciona igual: en lugar de duplicar información, hace una referencia.
Ejemplo visual:
Tabla: rental Tabla: customer
+----------+-------------+ +-------------+------------+
| rental_id| customer_id | ──→ | customer_id | first_name |
+----------+-------------+ +-------------+------------+
| 1 | 5 | | 5 | María |
| 2 | 5 | | 7 | Juan |
| 3 | 7 | | 12 | Ana |
+----------+-------------+ +-------------+------------+
El customer_id
en rental
es una Foreign Key que apunta a customer_id
en customer
.
Reglas de Foreign Keys:
- Debe existir en la tabla referenciada (integridad referencial), no puedes poner customer_id = 99 si no existe en customer.
- Puede repetirse (varios alquileres del mismo cliente)
- Puede ser NULL (si es opcional)
Ejemplo práctico:
-- Ver Foreign Keys en film_actor
SELECT
COLUMN_NAME,
REFERENCED_TABLE_NAME,
REFERENCED_COLUMN_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE TABLE_NAME = 'film_actor'
AND TABLE_SCHEMA = 'sakila'
AND REFERENCED_TABLE_NAME IS NOT NULL;
resultado: Esto te muestra que film_actor tiene Foreign Keys que apuntan a actor (por actor_id) y a film (por film_id), conectando actores con películas.
+-------------+-----------------------+------------------------+
| COLUMN_NAME | REFERENCED_TABLE_NAME | REFERENCED_COLUMN_NAME |
+-------------+-----------------------+------------------------+
| actor_id | actor | actor_id |
| film_id | film | film_id |
+-------------+-----------------------+------------------------+
Unique Key - Sin duplicados
Una Unique Key garantiza que no haya valores duplicados en una columna, pero a diferencia de Primary Key:
- Puede ser NULL
- Puede haber varias por tabla
CREATE TABLE usuarios (
user_id INT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(50) UNIQUE, -- No puede repetirse
email VARCHAR(100) UNIQUE, -- No puede repetirse
telefono VARCHAR(15) UNIQUE -- No puede repetirse
);
¿Por qué no hacer Primary Key de email
?
- Los emails pueden cambiar
- Es más eficiente buscar por número que por texto
- Puedes tener múltiples campos únicos