Discussion :

[hamster]

Bonjour,

voilà le contexte de mon problème :
J'ai une table T dans laquelle je stocke un nom et un code. Le code est une clef unique, calculée grâce à une fonction qui est appelée dans un trigger à l'insertion.
La méthode de calcul de ce code est la suivante : on prend les quatre premiers caractères alphabétiques du nom, auxquels on ajoute une séquence de 4 chiffres. Par exemple :

Code :

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

insert into T (nom) values ('Maison');

va valoriser le champ code avec MAIS0001.
Pour le calcul de la séquence numérique, on recherche la valeur max de SUBSTR(T.nom,5,4) et on y ajoute 1.

Code :

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

insert into T (nom) values ('Maisonnette');

va valoriser le champ code avec MAIS0002.

En revanche, si j'exécute les deux instructions dans la même transaction (sans commit),

Code :

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

1
2
insert into T (nom) values ('Chateau');
insert into T (nom) values ('Chaton');

et bien la deuxième instruction sera rejetée au motif que la règle d'unicité du champ code a été violée. Dans ma transaction même sans faire de commit, j'ai bien la visibilité de la première instruction. Si j'insère un select entre les deux, je verrai que le premier enregistrement a bien été créé (même s'il n'a pas encore été commité) ce qui ne semble pas être le cas de la fonction, qui elle ne le voit pas encore. Du coup elle considère que l'enregistrement 'Chateau' n'existe pas et essaie de valoriser T.code à CHAT0001 pour les deux lignes.

Mon besoin est d'insérer un très grand nombre d'enregistrements (potentiellement quelques centaines de milliers) et je me vois mal fixer ma fréquence de commit à 1.

Est-ce que vous savez comment je pourrais faire pour que ma fonction puisse "voir" que le premier enregistrement a déjà été créé, et ainsi le prendre en compte pour le calcul du T.code de l'enregistrement suivant ?

Merci pour toutes vos suggestions !

[mnitu]

Utilisez une séquence à la place du calcul du max sur la table (personnellement je ne utiliserait jamais de telles artifices pour le calcul d'une valeur de clé primaire).
En général la solution avec le max sur la table est une catastrophe.

[hamster]

Malheureusement l'utilisation de la séquence ne fonctionne pas ici. Le risque de colision avec un code déjà existant n'est pas nul. La table contient actuellement plus d'un million d'enregistrements, qui ont déjà tous un code unique. Si j'initialise à partir de maintenant une séquence, qui plus est la même pour tous les quadruplets de caractères possibles, je suis quasiment certain de retomber sur un code déjà existant.

[mnitu]

Malheureusement l'utilisation de la séquence ne fonctionne pas ici. Le risque de colision avec un code déjà existant n'est pas nul. La table contient actuellement plus d'un million d'enregistrements, qui ont déjà tous un code unique. Si j'initialise à partir de maintenant une séquence, qui plus est la même pour tous les quadruplets de caractères possibles, je suis quasiment certain de retomber sur un code déjà existant.

Franchement je n'ai pas pensé qu'en plus c'est du vrai .
Le vrai problème n’est pas le trigger mais l’insertion concurrente.
N’est-il pas envisageable d’ajouter une clé primaire ersatz (en anglais surogate primary key) donc un id_entite ?

[hamster]

Je ne saisi pas très bien ta proposition de clé primaire ersatz. Est-ce que tu peux m'en dire un peu plus ?

[mnitu]

Ajoute d'un colonne id_entite dans la table qui peut être valorisé pour les enregistrements existente avec des valeurs numériques (1, 2, 3, ... 1 000 000)et qui ensuite sera alimenté par une séquence et abandon de la clé primaire actuelle (celle avec max sur la table). Est-ce possible ?