Generación de Claves Primarias por parte de un Entity Bean en J2EE
TheServerSide: Entity Bean Primary Key Generator
Este artículo plantea la utilización de un Entity Bean que actúe como contador que se vaya incrementando. Como es un EBean, es distribuído, transaccional y persistente.
El bean contiene un atributo, long nextID, que contiene el valor en cada momento. Cuando se crea la clave primaria, el bean inserta en la "tabla" el nombre de la clave y el valor actual.
Este artículo es interesante tanto por lo que cuenta, como por cómo se llega a una solución más adecuada a partir de los comentarios de la gente. Este planteamiento de trabajo es mucho más ágil y lleva a mejores resultados que los típicos artículos -como puede ser éste mismo- sin opción a réplica.
En el artículo de Marinescu, se referencia un artículo de 1999, escrito por Scott Ambler, sobre generación de object identifiers:
El autor comenta que la utilización de claves con significado de negocio es muy peligroso, debido a que los cambios en esas columnas pueden provocar graves problemas en la integridad de la bbdd -p.e. si se cambiara el número de DNI o el Social Security USA-. Por ello, los gestores relacionales ofrecen lo que se denomina "surrogate keys", mediante claves incrementales. Estas claves son valores que se almacenan en tablas ocultas, y que se incrementan cada vez que se añade una fila de una tabla. El cómo se implementan estas tablas -valores globales para todas las tablas, o diferentes para cada una- depende del fabricante.
Además de esta estrategia, existen otras, como UUID (de la Open Software Foundation) y GUID (de Microsoft):
1. UUID: valores de 128 bits a partir de un hash del ID de Ethernet y la fecha sw.
2. GUID: hashes de 128 bits de un ID SW y la fecha.
¿Cuántos valores diferentes se pueden generar por segundo? Pues como los ordenadores actuales suelen representar el tiempo hasta milésimas de segundo, sólo podemos generar como mucho 1000 claves/segundo.
Además, las aplicaciones empresariales suelen ser multibases de datos, cada vendedor tiene una estrategia diferente, se da por hecho que existen comunicaciones constantes con las bases de datos para la obtención de la clave...
Ambler plantea una estrategia nueva denominada HIGH-LOW:
- El identificador se divide en dos partes:
1. Valor HIGH que se obtiene de una fuente definida.
2. Valor LOW que la propia aplicación se asigna a sí misma
- Cada vez que se obtiene un valor HIGH, el LOW se pone a 0.
Este artículo plantea la utilización de un Entity Bean que actúe como contador que se vaya incrementando. Como es un EBean, es distribuído, transaccional y persistente.
El bean contiene un atributo, long nextID, que contiene el valor en cada momento. Cuando se crea la clave primaria, el bean inserta en la "tabla" el nombre de la clave y el valor actual.
Este artículo es interesante tanto por lo que cuenta, como por cómo se llega a una solución más adecuada a partir de los comentarios de la gente. Este planteamiento de trabajo es mucho más ágil y lleva a mejores resultados que los típicos artículos -como puede ser éste mismo- sin opción a réplica.
En el artículo de Marinescu, se referencia un artículo de 1999, escrito por Scott Ambler, sobre generación de object identifiers:
El autor comenta que la utilización de claves con significado de negocio es muy peligroso, debido a que los cambios en esas columnas pueden provocar graves problemas en la integridad de la bbdd -p.e. si se cambiara el número de DNI o el Social Security USA-. Por ello, los gestores relacionales ofrecen lo que se denomina "surrogate keys", mediante claves incrementales. Estas claves son valores que se almacenan en tablas ocultas, y que se incrementan cada vez que se añade una fila de una tabla. El cómo se implementan estas tablas -valores globales para todas las tablas, o diferentes para cada una- depende del fabricante.
Además de esta estrategia, existen otras, como UUID (de la Open Software Foundation) y GUID (de Microsoft):
1. UUID: valores de 128 bits a partir de un hash del ID de Ethernet y la fecha sw.
2. GUID: hashes de 128 bits de un ID SW y la fecha.
¿Cuántos valores diferentes se pueden generar por segundo? Pues como los ordenadores actuales suelen representar el tiempo hasta milésimas de segundo, sólo podemos generar como mucho 1000 claves/segundo.
Además, las aplicaciones empresariales suelen ser multibases de datos, cada vendedor tiene una estrategia diferente, se da por hecho que existen comunicaciones constantes con las bases de datos para la obtención de la clave...
Ambler plantea una estrategia nueva denominada HIGH-LOW:
- El identificador se divide en dos partes:
1. Valor HIGH que se obtiene de una fuente definida.
2. Valor LOW que la propia aplicación se asigna a sí misma
- Cada vez que se obtiene un valor HIGH, el LOW se pone a 0.
Comments