Este artículo es el primer capítulo, extraído del libro "Database Design Book", de una serie dedicada a enseñar a diseñar las claves primarias de una base de datos a partir de los requisitos de negocio, en lugar de aplicar recetas genéricas. La parte 1 trabaja primero en el nivel lógico antes de saltar a las tablas.
El texto introduce el concepto de "external ID" (identificador externo): códigos que identifican de forma única una entidad en el mundo real, como números de referencia de repuestos, identificaciones fiscales (SSN, BSN), rutas URL como /about, identificadores de tickets (FOOBAR-123) o ASIN de Amazon. Un identificador externo válido debe cumplir tres propiedades: identifica exactamente una entidad en un momento dado (aunque pueda cambiar con el tiempo), una misma entidad puede tener cero, uno o varios, y su valor puede variar.
A partir de ahí se define el "anchor ID": un identificador inmutable y sin significado propio que se asigna internamente para referirse a cada instancia de un ancla de forma fiable. El caso habitual es un entero autoincremental (1, 2, 3…), aunque también se admiten cadenas únicas, tuplas o UUID.
El artículo distingue cuándo conviene usar el anchor ID directamente como identificador externo y cuándo es preferible generar un identificador externo aparte (por ejemplo, uno basado en fecha y número aleatorio) para no exponer el volumen real de negocio en operaciones secuenciales. También analiza los identificadores externos procedentes de sistemas ajenos, donde conviene evaluarlos con cuidado porque pueden estar duplicados entre países, falsificarse o carecer de la inmutabilidad necesaria, y a menudo conviene tratarlos como un atributo más del ancla en lugar de como clave.