Claves primarias: por qué el ID que enseñas al cliente no debe ser la clave

Alexey Makhotkin ha publicado la primera entrega de una serie sobre diseño de claves primarias, material que presenta como capítulo extra de su Database Design Book. La idea de fondo: antes de tocar tablas hay que decidir qué identificadores existen en el plano lógico y cuáles de ellos merecen ser la clave. La segunda parte, dedicada a las claves compuestas, queda pendiente.

IDs externos y anchor IDs

Un ID externo es cualquier identificador único que pueda salir del sistema: enviado en un correo, impreso en un papel o dictado por teléfono. Makhotkin le atribuye tres propiedades. Identifica a una entidad de forma unívoca, pero solo en un momento dado: un identificador puede reasignarse a otra entidad más adelante. Una entidad puede no tener ninguno, tener uno o tener varios, como los números de pieza y el ASIN de un mismo recambio en Amazon. Y puede cambiar: quien suelte su usuario de una red social deja el hueco libre para otro.

El anchor ID es otra cosa. Es el identificador interno que el sistema necesita para referirse a un registro sin ambigüedad: uno por registro y un registro por cada uno. En una base de datos con cien libros no sirve el ISBN, porque hay libros sin él, ni el título, porque puede haber cinco biblias distintas. La salida habitual son enteros que empiezan en 1. El requisito que importa es que sea inmutable, y un número sin significado lo cumple por definición: ID=2 no es mejor ni peor que ID=3, así que nunca hay motivo para cambiarlo. También valen cadenas únicas como "fr" o "CHF", tuplas de varios valores o UUIDs, que al final son enteros grandes no secuenciales.

Cuando el ID interno no debe salir de casa

Nada impide usar un anchor ID como ID externo, y se hace a diario. A veces es mala idea. En un comercio electrónico, los ID de pedido autoincrementales dejan que un competidor haga un pedido cada cierto tiempo y mida así el crecimiento del negocio ajeno. La alternativa que propone el autor es generar identificadores con fecha y parte aleatoria, del estilo 20261016-32767, y reservarlos para el trato con el cliente, mientras el entero sin significado sigue circulando por dentro.

Ese ID externo hay que validarlo y autenticarlo aunque lo haya generado el propio sistema: si llega una petición para cancelar una reserva, hay que comprobar que quien la manda tiene derecho sobre ese identificador.

En el plano físico, el texto defiende disociar por completo la clave primaria de su significado de negocio y lo ilustra con un sistema de gestión de contenidos mínimo: una tabla de anchors con clave entera, más las restricciones de unicidad y su relación con los IDs externos.

Para quien diseña esquemas, el recordatorio es útil: la clave que usa la base de datos y el identificador que ve el usuario responden a problemas distintos, y mezclarlos acaba costando. Falta ver cómo encaja todo esto con las claves compuestas en la segunda parte.