Cita:
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;
Cita:
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.
Cita:
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