Discussion :

[bugsman]

Bonjour,

Actuellement en stage dans le cadre de ma formation continue, je suis en train de rencontrer un problème sur la création d'une clé pour une base de donnée oracle sur laquelle j'ai des contraintes de formes.

La clé doit comporter pour le début au minimum les deux derniers chiffres de l'année et éventuellement le mois en cours, suivi de 4 chiffres en incrément automatique.

Comment gérer cela proprement ? Serait-il préférable de passer par une clé composite (AAMM + incrément) ou bien est il possible de créer une clé sous ce format dans oracle ?

Cordialement,

bugsman, apprenti SGBD

[pachot]

Bonjour,

Il faudrait savoir:
- si l'incrément se remet à zéro à chaque nouvelle année (ou nouveau mois)
- si l'incrément peut avoir des trous
- s'il y a beaucoup d'autres tables qui référencent cette clé.

si la réponse aux 3 est 'non' alors ça peut être simple. Sinon, ...

Cordialement,
Franck Pachot.

[bugsman]

Bonjour,

pour répondre à vos questions :
- L'incrément est remis à zéro chaque mois
- L'incrément ne peut pas avoir de trou
- Il y aura 4 tables qui utiliseront cette clé.

J'ai continué à me documenter, et un des articles sur la gestion de clé suggère éventuellement l'utilisation d'une table gérant l'incrément d'une clé. Est ce que ce serait une solution envisageable ?

Cordialement,
Bugsman, apprenti SGBD

[pachot]

- L'incrément ne peut pas avoir de trou

Alors dans ce cas je vois 2 solutions, parce qu'il faut tenir compte du fait qu'un insert peut être rollbacké pour n'importe quelle raison, et donc laisser un trou:
1. utiliser une table qui donne la valeur suivante, puis est incrémentée. Mais alors l'enregistrement de cette table sera vérouillé et il ne pourra pas y avoir plusieurs inserts en même temps -> pb de performance
2. ne pas utiliser cet incrément comme clé, mais comme une autre colonne qui sera mis à jour une fois que l'insert sera commité (en batch par exemple).
Cordialement,
Franck.

[bugsman]

Bonjour,

Le problème d'insert multiple ne se pose pas, parce qu'il est prévu qu'un seul utilisateur puisse effectuer les inserts utilisant ce numéro.

Je pense que la solution de la table donnant l'incrément est la solution la mieux adaptée, la difficulté restant tout de même l'unicité de ce numéro.

Je vais continuer à avancer sur l'application qui va gérer la base de données,et je verrais alors si cette solution fonctionne correctement ou non.

Merci pour votre réponse.
Bugsman, apprenti SGBD

[pachot]

Le problème d'insert multiple ne se pose pas, parce qu'il est prévu qu'un seul utilisateur puisse effectuer les inserts utilisant ce numéro.

Oui, mais un autre utilisateur voulant insérer un autre numéro devra attendre que le premier commite pour avoir le numéro suivant.

[bugsman]

Oui, mais un autre utilisateur voulant insérer un autre numéro devra attendre que le premier commite pour avoir le numéro suivant.

Dans l'absolu ce que tu dis est vrai. Dans l'utilisation de l'application, la table utilisant ce numéro comme une clé ne pourra être accédé que par un seul utilisateur.

Pour résumer l'application qui se cache derrière cette question, j'ai des utilisateurs qui effectuent une demande de problème (une table). Cette demande est analysée par un comité qui donne une réponse : acceptée, refusée, ou en attente de complément. Si la réponse est acceptée, la demande est transformé en problème (une autre table). C'est la table problème qui utilisera cette numérotation, et un seul utilisateur pourra transformer une demande de problème en problème, cette transformation étant effectué par le pilote du comité. Donc mon problème d'accès par plusieurs utilisateurs n'a pas lieu d'être dans mon cas, car il n'y aura pas plusieurs pilotes connectés en même temps.

Je reste tout à fait d'accord avec ta remarque, c'est simplement que le contexte de mon application permet cette manipulation peu élégante.

[pachot]

Alors ça devrait marcher