Discussion :

[tunis71187]

Bonjour,

J'ai une table où une colonne doit contenir des valeurs séquentielles automatiquement en utilisant l'instruction:

Code :

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

1
2
select nvl(max(to_number(NUMERO_S)),0)+1 into :NUMERO_S
from table;

c'est la clé primaire.

Je veux alimenter cette clé par une séquence mais le problème c'est que suite à une suppression ces numéros ne sont pas séquentiels.

Comment je peux assurer le séquencement des numéros.

Merci pour les propositions.

[Scriuiw]

Pas sur de bien comprendre !

L'instruction que tu montres est une séquence artisanale contrairement à une séquence gérée par Oracle.

Je veux alimenter cette clé par une séquence mais le problème c'est que suite à une suppression ces numéros ne sont pas séquentiels.
Comment je peux assurer le séquencement des numéros.

Si tu utilises une séquence tu auras un n° unique généré à chaque appel, mais suite à des suppressions tu auras des "trous".

Est-ce bien cela que tu entends par "suite à une suppression ces numéros ne sont pas séquentiels" ?

Tu veux combler les "trous" de la séquence ?

[bguihal]

le + simple serai de faire un trigger sur la table qui aille rechercher les trous et qui les remplisse.
et après tu remplace le :new.NUMERO_S par le nombre que tu a trouvé.
mais bon c'est pas tip top comme traitement, a chaque insertion tu va devoir rechercher.
tu ne peux pas remplacer cette clé primaire par une autre dans ta table ?

[tunis71187]

Merci pour les réponses.

Tu veux combler les "trous" de la séquence ?

Exactement, tenant l'exemple d'un bon de livraison ou autre qui doit avoir des numéros successives.

tu ne peux pas remplacer cette clé primaire par une autre dans ta table ?

Je peux remplacer cette clé par une autre mais le problème c'est que cette clé soit toujours contenant des numéros séquentielles même après suppression des données.

[bguihal]

alors le trigger est ton meilleur ami !

a l'interieur de celui ci tu parcourt tes numero jusqu'a un trou et tu le met dans :new.NUMERO_S

et tu le fait sur le "on insert".

[tunis71187]

Je pense que cela a des effets sur la performance en parcourant des milliers d'enregistrements !!!!

[pachot]

Bonjour,

alors le trigger est ton meilleur ami !
a l'interieur de celui ci tu parcourt tes numero jusqu'a un trou et tu le met dans :new.NUMERO_S
et tu le fait sur le "on insert".

Je pense que cela a des effets sur la performance en parcourant des milliers d'enregistrements !!!!

Surtout qu'il faudra vérouiller toute la table sinon quelqu'un peut refaire des trous dans ce que tu as déjà lu !

vraiment je n'ai pas pensé que c'est assez compliqué car actuellement, sur l'application je cherche le max du clé et en pre-insert j'alimente le champ.

Là aussi, il faut vérouiller la table pour qu'il n'y ait pas 2 inserts en même temps.

Exactement, tenant l'exemple d'un bon de livraison ou autre qui doit avoir des numéros successives.

Est-ce qu'en cas de suppression il faut (1) tout renuméroter (je suppose que non) ou (2) simplement réutiliser le numéro plus tard ?
Et s'il faut le réutiliser plus tard, est-ce qu'on peut (2a) se permettre d'attendre et qu'il y ait un trou pendant un certain temps, ou faut-il (2b) le réutiliser tout de suite au prochain insert ?

Le (1) peut se résoudre en calculant le numéro au moment du select et non de l'insert.
Le (2a) peut s'implémenter en faisant une file d'attente de numéros à réutiliser.
Le (2b) serait beaucoup plus complexe. Un delete devrait s'assurer qu'il n'y a aucun insert en cours, puis faire le delete mais ne commiter que lorsque une autre transaction aura réutilisé le numéro.

Mais un bon de livraison, c'est simple. Il ne devrait jamais être supprimé. Du moins une fois qu'il a été imprimé ou envoyé à un système externe.

Si on a besoin d'en supprimer un qui vient d'être saisi, alors il faudrait avoir une numérotation en batch asynchrone: on saisit des bons de livraison 'brouillon' sans numéro et un batch périodique fait passer tous les brouillons à l'état valide en les numérotant.

Cordialement,
Franck.

[mnitu]

Pour s'enfuir du problème d'accès concurrent je veux juste une méthode qui me permet d'assurer le séquencement.

On ne peut pas s’enfuir du problème d’accès concurrent que si vous est le seul utilisateur de la base. Une table de compteur réponde à votre demande mais peut constituer un point d’étranglement dans votre application si des milliers des utilisateurs saisis simultanément des bons de commande.

@pachot

...
Un delete devrait s'assurer qu'il n'y a aucun insert en cours, puis faire le delete mais ne commiter que lorsque une autre transaction aura réutilisé le numéro.
...

Je m’imagine l’application vendredi soir après que le dernière utilisateur viens de supprimer le bons de commande et ferme la lumière derrière lui.