Questions sur les séquences

Bonjour,
je stocke dans une table une liste d'entités déterminées qui peuvent être au maximum de 99 tout en ayant un identifiant allant de 1 à 99.
J'ai donc naturellement créé une séquence allant de 1 à 99 pour pouvoir gérer une surrogate key les identifiants....
Mon application permet ensuite de supprimer une de ces entités si elle n'est plus utilisée. Du coup je me retrouve avec des trous dans la séquence que j'aurais souhaité pouvoir réutiliser...
J'aurais voulu savoir quelle était la meilleure façon de s'y prendre... Car la seule manière que je vois c'est de modifier tous mes ordres d'insertion pour qu'ils cherchent en priorité le premier gap dans la séquence avant d'insérer..
Pour une requête en one-shot pourquoi pas : mais pour un traitement par batch?

Merci pour vos avis sur la question,
Lek

Bonjour,


Actuellement comment vous faites exactement la mise à jour de votre table? C'est à dire par exemple à partir d'un fichier de données avec SQL*Loader ou un fichier script avec des INSERT?

Ainsi, comment vous faites actuellement la mise à jour de la clé associée à chaque item? Manuellement avec un UPDATE?


Cordialement,

Bonsoir,
actuellement j'ai une appli web qui permet de faire des insertions dynamiques via des procs avec des requêtes du genre :

Code:

---

1 2 3 4 5 6 7

INSERT INTO ma_table (table_id, label) VALUES (seq_table_id.NEXTVAL, 'Un libelle');   update ma_table set label = 'nouveal label' where table_id=pTableId;

---

A l'installation de l'appli (et parfois en cours de vie de l'application dans ce cas j'utilise des merge) il peut y avoir des imports via des tables externes, j'ai alors une requête du genre :

Code:

---

1 2 3 4

insert into ma_table (table_id, label) select seq_table_id.NEXTVAL, tmp_lib from table_externe ;

---

Bonjour,

Une séquence n'est pas faite pour ça :)
Un identifiant est une donnée purement technique, peu importe qu'il y ait des trous et il ne faut pas chercher à avoir des numéros précis. Par ailleurs, réutiliser des ID peut causer des problèmes s'ils sont utilisés ailleurs comme référence.

Si les numéros de 1 à 99 ont une signification fonctionnelle, il faut utiliser autre chose qu'une séquence pour les gérer et les utiliser comme clé secondaire en gardant un ID technique. Si ce n'est pas la cas, gardez uniquement votre ID technique.

Citation:

---

Envoyé par FSiebert

... Si les numéros de 1 à 99 ont une signification fonctionnelle, il faut utiliser autre chose qu'une séquence pour les gérer et les utiliser comme clé secondaire en gardant un ID technique ...

---

Très bonne remarque, justement comme un ensemble relationel les éléments ne sont pas ordonnés dans une table oracle. En plus dans le cas d'un accès concurrent et le problématique de synchronisation je me demande s'il pourra garantir la contiguïté des valeurs associées.

A la limite, moi ce que je ferrais c'est créer une vue objet (ou même une vue ordinaire) sur la table ensuite un trigger BEFORE INSERT UPDATE sur cette vue, puis je pointe l'appli sur cette vue au lieu de tapper directement la table (sinon on aura le problème classique de ORA-04091: table XXXX is mutating).

Ensuite à l'intérieur de ce trigger je declare un Nested Table dont le type aurait été déjà déclaré au niveau de schéma, par exemple

Code:

---

1 2	SQL> CREATE TYPE tab_ty IS TABLE OF votretable%ROWTYPE;

---

Et c'est à l'intérieur de ce trigger où je récupère la totalité du contenu de la table en question. Etant donné qu'il n'y a que 99 éléments l'impact d'un point de vue de la performance ne sera pas si important que ça (mais bon après il faut quand même prendre en comtpe la fréquence d'accès sur la table).

Bref, à l'intérieur d'une LOOP je peux parcourir la table, faire les mise à jour requises, voir trier les éléments si besoin et générer à nouveau un ID itérative (qui peut très bien être simplement le compteur de mon boucle éventuellement concatené avec un prefix pour lui donner une apparence de clé). Finalement vous faite une mise jour de la table principale à partir de l'objet de collection (Nested table)


Cordialement,

Bonjour,

L'ERP sur lequel je travaille utilise pour ça deux tables, donc voici la structure simplifiée :

Une table "compteur" :
id_compteur
min
max
increment
valeur

Une table "trou" :
id_trou
id_compteur (fk vers compteur.id_compteur)
valeur

Lors de la suppression d'une ligne, on ajoute une ligne dans "trou" avec la valeur supprimée, pour le bon code compteur (numéro de commande, facture, etc.)
Lors de l'insertion d'une ligne, on interroge en premier la table compteur, pour retrouver le min/max pour le compteur.
On vérifie alors si dans la table "trou" on trouve une valeur comprise entre min et max pour le compteur. Si c'est le cas, on prends cette valeur, et on supprime la ligne dans trou. Sinon, on incrémente (selon l'incrément, et tant que ça reste en dessous du max) la valeur de la ligne de compteur, et on utilise cette valeur pour l'insertion.

Bonjour,


Quel est exactement l'intérêt de cette numérotation dans votre ERP? (Étant donné que chaque table a sa propre clé normalement)


Cordialement,

Dans cet ERP, l'intérêt c'est que les le numéro de pièce n'est pas la clé, mais une partie de la clé.
Il n'y a qu'une seule table d'événements, qui contient à la fois les commandes, factures, livraisons, etc. puisque ces éléments ont la même structure.
Ceci permet notamment d'avoir des flux aussi simples que complexes, sans toucher à la structure des données.

Aussi, dans la même base, même schéma, peuvent cohabiter plusieurs sociétés (centrale, filiale, dépôt, magasin, etc.) et évidement, chaque société peut avoir les mêmes numéros de pièce pour des documents différents. Par conséquent, on doit gérer la numérotation par un autre moyen que des séquences (ou alors il faudra des dizaines de séquences, créées dynamiquement, ce qui n'est pas terrible pour la maintenance).

Merci pour cette technique StringBuilder, c'est pas mal comme approche.

Juste pour ré-insister, n'utilisez pas cette technique pour générer une PK. Il n'y a aucun intérêt à ce qu'une PK soit sans trous, etc.

Citation:

---

Envoyé par FSiebert

... Il n'y a aucun intérêt à ce qu'une PK soit sans trous, etc ...

---

A mon avis, ça dépend du contexte et l'outil utilisé. Si c'est bien pensé et organisé dès le début effectivement la clé est indépendante de la séquence. Mais il y a des ERP où la question de la séquence est un sujet intrinsèque de l'outil. Par exemple dans SAP, la clé de la table des équipements est simplement un numéro du genre 10000001, 10000002, 10000003, etc. Et quand on regarde le code ABAP de certaines transactions notamment quand il s'agit de parcourir une table transparente (STANDARD TABLE) à l'intérieur d'une boucle, on peut voir que le programme fait une simple incrémentation du numéro pour passer à l'équipement suivant. Ici avoir des trous serait problématique.

En même temps, si tu supprimes deux lignes et que tu n'en n'insère qu'une, il reste un trou, donc ça posera problème.

Si on veut garantir l'absence de trou, on doit renuméroter toutes les lignes qui se trouvent après le trou à chaque création d'un trou, ce qui me semble particulièrement lourd.

Citation:

---

Envoyé par StringBuilder

En même temps, si tu supprimes deux lignes et que tu n'en n'insère qu'une, il reste un trou, donc ça posera problème.

---

Justement c'est ça qui est dingue dans SAP, tu ne les supprime pas physiquement, tu les archives! (en gros le système colle une étiquette sur le n° de séquence pour que celui-ci ne soit plus utilisé).

Il n'y a pas de renumérotation. La numérotation va toujours dans un seul sens, toujours prendre le dernier ajouter 1 pour passer à l'équipement suivant.

Citation:

---

Envoyé par dariyoosh

Il n'y a pas de renumérotation. La numérotation va toujours dans un seul sens, toujours prendre le dernier ajouter 1 pour passer à l'équipement suivant.

---

Quelle différence avec une séquence du coup ?
Si c'est le fait d'utiliser des chiffres du genre 1000001, je préférerai une clé composite (100000, 1) où la deuxième colonne utilise une séquence pour l'incrémentation (ça évite le problème d'atteindre 199999 aussi).
Et dans ce cas je verrai quand même plutôt ça comme une clé secondaire.

Citation:

---

Envoyé par FSiebert

Quelle différence avec une séquence du coup ?

---

C'est belle et bien une séquence. D'ailleurs c'est un grand classique chez SAP avant déployer chaque nouveau module (MM, PM, SRM, etc.) il y a des modes opératoires à dérouler pour bien définir une fois pour tout les tranches de numéros pour les articles, équipements, postes techniques, postes de travail, etc.

Merci pour vos avis et conseils respectifs.
Après réflexion, je suis d'accord sur le fait que j'ai peut être mélangé deux concepts différents : après avoir revu la définition fondamentale d'une séquence il est clair qu'elle reste un instrument technique qui ne peut me garantir l'absence des trous et qui ne peut pas être utilisé dans mon cas...
Je vais replancher le sujet pour trouver une solution plus appropriée.
Merci encore.