Cuando trabajamos con bases de datos relacionales, los identificadores únicos de registro son imprescindibles. Es verdad que siempre se pueden encontrar claves candidatas semánticas, pero para establecer relaciones entre tablas, nada como usar un solo campo numérico. Esto mejora la velocidad y simplifica las consultas.  Si además ese campo no tiene valor para el negocio, no habrá que preocuparse de renumeraciones, huecos, lotes …

En sistemas centralizados la generación de identificadores únicos no representa mayor problema, ya que los fabricantes nos ofrecen mecanismos de generación secuencial de números para identificar nuevos registros. Pero si quisiéramos un mayor control que evitase huecos o aportase algún valor  semántico a los códigos, nos bastaría con implementar algún sistema de contadores personal. El más común, se basa en una tabla en la que se almacena el último número emitido. Dicha tabla de contadores debe estar protegida y sólo debe ser accesible a través de un procedimiento que calcule, devuelva y registre el valor siguiente para un contador.

Las bases de datos distribuidas complican la generación de identificadores únicos, pues  tanto los autonuméricos como los contadores personalizados son irrepetibles sólo dentro de un ámbito, ya sea este una instancia de base de datos personal, un servidor de bases de datos dedicado o una red local de servidores. Pero esto no es válido para sistemas desconectados como pueda ser la red de tiendas de una multinacional que requiera la consolidación cuasi online de los datos producidos.

De nuevo, hay soluciones estándar como el UUID y la implementación GUID de Microsoft que garantizan razonablemente la universalidad de los códigos generados. A cambio, el coste es tremendo: ¡cada código ocupa 16 bytes!. Conviene recordar que el tipo de datos estándar int ocupa sólo 4 bytes, y que para tablas realmente enormes podríamos usar el bigint de 8 bytes. Además, aunque el gigantesco GUID se almacena en 4 bytes, no se muestra como un número, si no como un churro de 32 caracteres muy poco user friendly a la hora de realizar consultas directas contra la base de datos.

La solución por la que hemos optado en Lusco combina la generación local de contadores, con un identificador del terminal que los generó. El resultado es un número único dentro del universo de nuestra aplicación. Este patrón obliga a registrar cada instancia de base de datos en un servidor central, pero esto, lejos de ser un inconveniente ayuda a gestionar un parque numeroso de instalaciones… aunque eso ya es materia para otro post.