Identificadores de entidades I: ¿cuál es el mejor modo de identificar entidades?

Es un viejo debate, que puede llegar a ser áspero, determinar cuál es el mejor modo de identificar entidades en un sistema. Voy a repasar los métodos que he conocido y mostraros que, aunque no he encontrado recetas mágicas, al menos, un mayor conocimiento de las alternativas y su aplicación lógica ayuda a elegir el patrón de identificación adecuado para un sistema.

Para empezar fijaos en la intencionalidad del término entidad y no registro, más propio del mundo tabulado, pues desde el prisma de un desarrollador lo que tenemos delante es un modelo semántico de un negocio que tratamos de representar. Su identificación suele emanar directamente del propio negocio en forma de los que llamamos claves naturales y forma parte del propio modelo.

La primera gran cuestión, diría que la más dolorosa, es la que me lleva a descartar el uso de esas claves naturales para la identificación de entidades. Es dolorosa porque, se haga como se haga, significa agregar al menos un atributo a cada entidad para no aportar valor semántico ni de negocio alguno.

Pero la alternativa es peor, tanto en rendimiento como en riesgo de cambios. Las claves naturales, a menudo están compuestas por más de un atributo, o estos son pesados por naturaleza, y ambos factores inciden muy negativamente en el rendimiento de los sistemas si se comparan con el uso de campos numéricos. Por no hablar de cambios en el negocio que hagan que una clave… deje de serlo.

Descartadas pues las claves naturales, hemos de buscar un artificio que de una manera sistemática genere códigos capaces de identificar entidades. Para empezar tendremos dos posibles fuentes de generación: nuestro programa, o el propio gestor del almacenamiento.

En entornos homogéneos, donde las entidades acaban todas en el mismo repositorio, y éste es único, la solución del gestor de bases de datos es mi preferida. Sí, estamos hablando del campo autonumérico. Es fácil de usar, y por tratarse de números enteros acotados, ocupa relativamente poco, podemos usar versiones de cuatro u ocho bytes y tiene un rendimiento excepcional. En mi opinión siempre debemos justificar cualquier solución distinta al uso de un autonumérico. Pero hay situaciones para ello.

Una excepción podría ser no usar autonuméricos para las tablas que expresan relaciones n:m y que por tanto disponen de una clave natural formada por los dos atributos foráneos autogenerados. Aunque en aras de la homogeneidad y favoreciendo los sistemas basados en convenciones, recomiendo usar el mismo patrón generador para todas las entidades.

Tampoco bastan los autonuméricos en el caso de sistemas distribuidos, con muchas bases de datos comunicándose, o integrando datos. En esas situaciones no garantizaremos la unicidad de los autonuméricos sin esfuerzo. El mínimo será actuar sobre el salto y la semilla en cada tabla de cada base de datos. Es decir si tengo dos bases de datos puedo usar un salto dos e iniciar una base de datos en uno y la otra en dos. Este sistema se viene abajo en cuanto aparece la tercera instancia de base de datos. Podríamos ser previsores y usar un salto mayor… pero ¿Quién apuesta?

Otro problema que no resuelven los autonuméricos de base de datos es aquel en el que las entidades se guardan ¡no sólo en bases de datos! Con el auge de las bases de datos documentales cada vez es más frecuente encontrarnos con entornos mixtos inevitablemente más complejos que los homogéneos. En estos casos disponer de generadores de códigos comunes puede ser una ventaja, pero no vale el autonumérico.

Para finalizar tenemos que prestar atención a otros códigos de negocio, que por obligación legal deban ser secuenciales; en ese caso no es trivial garantizar la ausencia de huecos usando los autonuméricos de base de datos.
En resumen, como primera aproximación debemos evitar a toda costa el uso de claves naturales e inclinarlos, si la solución lo permite, por el uso de códigos autonuméricos, sencillos, fiables y rápidos.

Foto | Proscilas (Flickr)