Consejo secuencia

[rcastellanossuarez]

Buenos dias:
Tengo la siguiente duda , tengo que implementar campos autoincrementables en mi aplicación y no se si definir una secuencia por cada tabla o una secuencia que sea utilizada por todas las tablas, no se si usar una sola pueda tener impacto en el rendimiento de la aplicación o traerme algún otro problema, por otra parte serían muchas tablas y por tanto serían muchas secuencias si hago una para cada una
gracias de antemano espero recomendaciones

[matanga]

Es perfectamente válido tener una única secuencia para todas las tablas, de todos modos, si son muchas tablas y además muchos usuarios concurrentes, también es válido pensar que puede haber problemas de contención (esto es en teoría, hasta donde sé no hay test de rendimiento con secuencias).

Por lo general, yo utilizo una secuencia para cada tabla (la cantidad de secuencias no tiene costo) y una secuencia para un subconjunto de tablas si las tablas contienen datos excluyentes. El caso de una secuencia para todas las tablas, aunque nunca lo utilice, lo dejaría para un modelo de pocas tablas.

Saludos

[rcastellanossuarez]

gracias por responder matanga aunque no entiendo bien a que te refieres con tablas que contienen datos excluyentes te agradecería me explicaras un poco más
saludos

[gnzsoloyo]

Iniciado por rcastellanossuarez

Buenos dias:
Tengo la siguiente duda , tengo que implementar campos autoincrementables en mi aplicación y no se si definir una secuencia por cada tabla o una secuencia que sea utilizada por todas las tablas, no se si usar una sola pueda tener impacto en el rendimiento de la aplicación o traerme algún otro problema, por otra parte serían muchas tablas y por tanto serían muchas secuencias si hago una para cada una
gracias de antemano espero recomendaciones

Partamos de la base que una secuencia es un objeto que precisamente se usa coo identificador autoincremental único. Esto significa que es muy común usarlo como clave primaria numérica de una única tabla, gracias a su unicidad.
No existe un impedimento concreto para usar la misma secuencia en diferentes tablas, pero resulta algo medio extraño por el uso original que se le da.
Plantear usar una misma seceuncia para diferentes tablas tiene al menos una consecuencia bastante rara: No existirá secuenciación incremental en la misma tabla, ya que diferentes números generados en la secuencia terminarán siendo el ID de diferentes tablas.
Esto puede no generar problemas reales, pero además puede generar enormes "huecos" de numeración en una misma tabla (menos usada), mientras que en otras (más usadas), las numeraciones tenderá a ser mas consecutivas.
Este tipo de cosas puede generar problemas si la secuencialidad de los números es importante para algún proceso, por ejemplo. En esos casos no parece ser una buena idea.
Ahora bien, a mi juicio es más "fiaca" de DBA que una opción razonable.
Si es la cantidad de secuencias la que te preocupa, eso se resuelve con una buena documentación de desarrollo, y buenos patrones mnemotecnicos para recordar a qué pertenece cada secuencia.
Por mi parte, trabajo con una base en Oracle que cuenta con más de 900 tablas, donde casi todas (más del 80%) poseen secuencias asignadas. E incluso tengo tablas donde hay más de dos secuencias asignadas a ella, producto de necesidades del sistema.
Y lo que puedo asegurarte es que no nos traen ningún tipo de problemas...

[rcastellanossuarez]

Gracias, me han respondido mi duda

[matanga]

Iniciado por gnzsoloyo

Plantear usar una misma seceuncia para diferentes tablas tiene al menos una consecuencia bastante rara: No existirá secuenciación incremental en la misma tabla, ya que diferentes números generados en la secuencia terminarán siendo el ID de diferentes tablas.
Esto puede no generar problemas reales, pero además puede generar enormes "huecos" de numeración en una misma tabla (menos usada), mientras que en otras (más usadas), las numeraciones tenderá a ser mas consecutivas.
Este tipo de cosas puede generar problemas si la secuencialidad de los números es importante para algún proceso, por ejemplo. En esos casos no parece ser una buena idea..

Es correcto concluir que una única secuencia genera huecos en la numeración de los registros, pero también se debe tener en cuenta que:

1. Si el objetivo es generar una PK Sustituta, los huecos en la numeración son irrelevantes, ya que los valores de una PK Sustituta no tienen significado para el modelo, solo deben cumplir con la condición de ser únicos y not null.

2. Si el objetivo es generar números correlativos, las secuencias son inviables, aún cuando tengas una por cada tabla habrá problemas en casos como:

Una sentencia insert que finaliza con error (valor null en el campo nombre), en este caso, el rollback no deshace el incremento de la secuencia y se pierde la correlatividad.

Código:

create sequence seq
 start with 1
 increment by 1;

create table t1 (
 id number(8) primary key,
 nombre varchar2(10) not null );

insert into t1 (id, nombre) values (seq.nextval, null);

Una secuencia con cache, teniendo en cuenta que el valor actual de una secuencia se guarda en una tabla de sistema y que se actualiza con una sentencia update, puedes definir la opción nocache para que se ejecute un update por cada nextval, o como el ejemplo, definir la opción cache=10 que permite prealocar en memoria los siguientes 10 números de la secuencia y se ejecute un update cada 10 nextval, en este caso, un caída inesperada de la instancia no deshace el incremento de los valores prealocados y se pierde la correlatividad.

Código:

create sequence seq
 start with 1
 increment by 1
 cache 10;

select seq.nextval from dual;

shutdown abort;

Iniciado por gnzsoloyo

Si es la cantidad de secuencias la que te preocupa, eso se resuelve con una buena documentación de desarrollo, y buenos patrones mnemotecnicos para recordar a qué pertenece cada secuencia.

100% de acuerdo, esto es clave, utilizar la secuencia equivocada puede provocar errores en los campos unique o pk.

Iniciado por rcastellanossuarez

...no entiendo bien a que te refieres con tablas que contienen datos excluyentes te agradecería me explicaras un poco más..

Esto suele pasar cuando necesitas resolver la herencia de un lenguaje orientados a objetos en bases de datos relacionales, por ejemplo, si tienes las clases Casa y Apartamento que heredan de la clase Inmueble, puedes almacenar los datos en la base creando:

1. Una tabla, TInmueble con el campo IdInmueble.
2. Tres tablas, TInmueble con el campo IdInmueble, TCasa con los campos IdInmueble,IdCasa, y TApartamento con los campos IdInmueble,IdApartamento.
3. Dos tablas, TCasa con el campo IdCasa y TApartamento con el campo IdApartamento.

Después, en POO es muy probable que quieras construir una colección de objetos tipo Inmueble (ej: para un patrón strategy) donde el ObjectId de cada objeto (valor unique dentro de la colección) sea el valor que identifica el registro en la base de datos, en estos casos, con el modelo 1 tienes IdInmueble (seq_inmueble), con el modelo 2 tienes el par IdInmueble,IdCasa y IdInmueble,IdApartamento (seq_inmueble, seq_casa, seq_apartamento), y en el modelo 3, solo puedes asegurar la unicidad de ObjectId si los identificadores IdCasa y IdApartamento son excluyentes (seq_casa_apartamento).

Saludos