Discussion :

[LEK]

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

[dariyoosh]

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,

[LEK]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[FSiebert]

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.

[dariyoosh]

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

Sélectionner tout - Visualiser dans une fenêtre à part

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,

[StringBuilder]

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.