Discussion :

[M4veR1K]

Bonjour,

J'ai une base où pour la quasi-totalité de mes tables, j'ai mis en place le système d'auto-incrémentation classique avec la séquence et le trigger.

Par exemple:

Code :

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

1
2
3
4
5
6
7
8
9
CREATE SEQUENCE seq_users START WITH 1 INCREMENT BY 1;
 
CREATE TRIGGER trg_users 
BEFORE INSERT ON USERS 
FOR EACH ROW
BEGIN
select seq_users.nextval into :new.id from DUAL;
END;
/

La question que je me pose, c'est pourquoi les IDs que j'ai en base actuellement sont si grand par rapport à mon nombre d'entrées? A titre d'exemple, le dernier ID généré doit être 1600 et des broquilles alors que j'ai pas plus de 400 entrées en totalité dans la base. Ça donne l'impression que toutes les tables partagent une séquence unique (ce qui n'est évidemment pas le cas).

Je veux bien que ça incrémente l'id même quand une requête d'INSERT foire, mais bon, c'est quand même assez rare.

[McM]

Je ne comprends pas ta phrase :

Ça donne l'impression que toutes les tables partagent une séquence unique (ce qui n'est évidemment pas le cas).

Tu as une séquence par table ?

Les séquences permettent d'avoir la certitude de l'unicité, par contre tu peux avoir des trous.
Les valeurs des séquences sont mises en cache (par défaut, c'est par 20 je crois), donc il suffit que le cache soit purgé [arrêt de base / flush shared pool, etc..], et tu "perds" les n° non utilisés.

[Rei Ichido]

Je veux bien que ça incrémente l'id même quand une requête d'INSERT foire, mais bon, c'est quand même assez rare.

Il suffit que la séquence soit appelée pour que l'incrément soit fait. Par exemple, une application peut appeler la séquence pour fixer un identifiant à un nouvel enregistrement (mettons, une commande en ligne).
Mais finalement, l'utilisateur ne valide pas, il y a un logout, etc.
Résultat, un n° non utilisé.

=> Il faut bien voir que ça n'a pas d'importance. Ce qui est important, c'est l'insertion (presque) dans l'ordre, la clé de petite taille, et l'unicité.

[Bibeleuh]

Comme l'a dit McM il y a par défaut un cache de 20, du coup si tu souhaites supprimer ce cache il faut préciser à la création de la séquence :

Code :

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

1
2
 
CREATE SEQUENCE seq_users START WITH 1 INCREMENT BY 1 NOCACHE;

Cependant la mise en cache peut permettre d'obtenir des gains en performance, à toi de voir

[M4veR1K]

Merci pour vos réponses. Je comprends mieux désormais.

J'ai fait pas mal d'appli avec l'auto-incrémentation (quand j'étais étudiant, et maintenant en entreprise) et je m'étais toujours demandé: "mais pourquoi des fois il y a de gros trous au niveau des identifiants ?".

Effectivement, comme dit Rei Ichido, ça n'a peu d'importance, à partir du moment où j'ai bien un numéro unique pour chaque entrée.

Par contre, ça réduit la durée où il va falloir remplacer les int par des long pour es identifiants dans les modèles de données ^^

Merci pour l'astuce du NOCACHE Bibeleuh. Néanmoins, si ne pas le mettre permet un gain de performance, alors autant de pas l'utiliser

[Waldar]

Par contre, ça réduit la durée où il va falloir remplacer les int par des long pour es identifiants dans les modèles de données ^^

C'est un faux problème.
Même en prenant un NUMBER(15) sachant qu'Oracle va naturellement jusqu'à un NUMBER(38), avec 100.000 insertions par seconde il faut un peu plus de trois siècles pour arriver à la limite de la colonne.
Alors même s'il y a 80% de trous dans la séquence, ça laisse encore 60 ans de répit, et à priori vous n'avez pas vraiment 100.000 insertions par seconde.

Merci pour l'astuce du NOCACHE Bibeleuh. Néanmoins, si ne pas le mettre permet un gain de performance, alors autant de pas l'utiliser

Le gain a lieu lors d'insertions massives de données.
Si c'est dans votre application et que vous insérez généralement les lignes une à une, vous ne constaterez probablement pas de différence.

[McM]

En fait, pour l'optimisation du cache, une séquence très fréquemment utilisée, il faut monter la valeur du cache.
Imagine un traitement qui crée 1000 lignes / seconde pendant quelques minutes..

Code :

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

CREATE SEQUENCE seq_users START WITH 1 INCREMENT BY 1 CACHE 200;

Pour savoir la valeur optimale à mettre, c'est au feeling.
Quand au gain de perf, je ne pense pas qu'il se voie sur un seul traitement, mais la base s'en sentira mieux.

[M4veR1K]

C'est un faux problème.

Je parlais d'un mapping avec un langage de programmation qui utilise des int (java). Mais je viens de me renseigner à l'instant, et il y a de la marge de ce côté ici aussi.

Si c'est dans votre application et que vous insérez généralement les lignes une à une, vous ne constaterez probablement pas de différence.

Ha, dans ce cas la, je suis parti pour cette solution.

Merci McM pour ces astuces, c'est bon à savoir!

[Pomalaix]

En fait, pour l'optimisation du cache, une séquence très fréquemment utilisée, il faut monter la valeur du cache.

De mon expérience, la valeur par défaut de 20 pour le cache est très bonne, et seuls des tests artificiels (boucle qui ne fait que des incrémentations de séquence, sans rien d'autre d'utile) bénéficient d'un cache supérieur. Et encore, au-delà de 100, je ne voyais même pas d'amélioration.

Par contre ça serait intéressant que vous précisiez dans quel contexte de traitement réel (nombre de sessions simultanées, insertions par seconde, etc) vous avez pu voir une vraie amélioration en augmentant le cache.
Et le fin du fin, ça serait une mesure de l'amélioration obtenue.

Pour info, il existe dans V$SESS_TIME_MODEL une statistique "sequence load elapsed time" qui indique le temps passé à obtenir le NEXTVAL des séquences qui n'ont pas de cache, ou le temps passé à alimenter le cache pour les séquences qui en ont.