Definición
La clave primaria es el campo —o la combinación de campos— que identifica de forma única a cada fila de una tabla.
Cumple tres condiciones: es única, nunca está vacía y no cambia. Esa tercera es la que se incumple sin darse cuenta y la que más problemas causa.
Junto a ella aparece siempre su pareja: la clave foránea, que es un campo de otra tabla que apunta a esa clave primaria. Así es como una base de datos relacional conecta pedidos con clientes o líneas con pedidos.
Natural o artificial
Clave natural. Un dato real del negocio que ya identifica la fila: el NIF de un cliente, la referencia de un producto, la matrícula de un vehículo.
Clave artificial. Un número o identificador generado por el sistema, sin significado alguno.
Y aquí va la recomendación, que va contra el instinto: usa clave artificial casi siempre.
El motivo es que los datos del negocio cambian, aunque nadie lo espere. Una referencia de producto se reestructura, un NIF se corrigió mal al darlo de alta, un código de cliente se unifica tras una fusión. En cuanto ese dato es la clave primaria, cambiarlo obliga a modificar todas las tablas que lo referencian, y cualquier fallo a mitad deja huérfanos.
Con una clave artificial, esos datos siguen existiendo como campos normales, con su índice único si hace falta — pero cambiarlos es una actualización de un campo, no una cirugía.
Ejemplo práctico
En un sistema comercial, la tentación clásica es usar la referencia del producto como clave primaria. Es única, es la que todo el mundo usa, parece perfecta.
Lo que aprendí: el día que el fabricante reestructura su catálogo y cambia la nomenclatura, esa decisión se paga entera. Precios especiales, líneas de pedido, histórico de compras, fichas técnicas: todo apunta a un código que ya no existe. Y no se puede simplemente renombrar, porque hay que hacerlo en todas partes a la vez y sin que nadie escriba mientras tanto.
Con un identificador interno como clave primaria y la referencia como campo indexado, ese mismo cambio es una línea de actualización.
El segundo aprendizaje, sobre claves compuestas: a veces la clave primaria es la combinación de dos campos —cliente más producto, por ejemplo, en una tabla de precios negociados—. Es correcto y expresa bien la regla real: un solo precio por cliente y producto. Y tiene un coste que conviene conocer: las tablas que referencien esa fila necesitan arrastrar los dos campos, y las consultas se vuelven más verbosas.
La regla práctica: clave compuesta cuando la tabla solo existe para relacionar dos entidades; clave artificial cuando la fila es una entidad por sí misma.
Y una advertencia sobre los identificadores visibles: si el identificador aparece en una URL o en un documento, un número correlativo revela cuántos registros tienes y permite ir probando vecinos. Para lo que se expone al exterior conviene un identificador que no sea adivinable — y, sobre todo, comprobar siempre en el servidor que ese usuario puede ver ese registro.
Errores comunes
- Usar un dato del negocio que puede cambiar.
- No declarar clave primaria. Sin ella, dos filas idénticas pueden convivir y no hay forma limpia de borrar una.
- No declarar las claves foráneas, dejando que la base de datos acepte referencias a filas inexistentes.
- Reutilizar identificadores de filas borradas.
- Clave compuesta de cuatro campos donde bastaba un identificador propio.
- Exponer identificadores correlativos y fiarse de que nadie pruebe el siguiente.
- Cambiar la clave primaria en producción sin plan de migración. Ver migración de base de datos.
Cuándo decidirlo
Al diseñar cada tabla, antes de la primera línea de código. Es la decisión con peor relación entre lo que cuesta acertar y lo que cuesta corregir.
La pregunta que resuelve casi todos los casos: ¿este valor podría cambiar alguna vez, aunque hoy parezca imposible? Si hay la menor duda, no es tu clave primaria.
