Discussion :

[blapointe]

Bonjour à tous!

Je viens avec une question relativement simple. Cependant, je n'ai pas trouvé de réponse après une longue matinée de recherche...peut être allez vous pouvoir m'aider.

Imaginons que j'aie une table client avec deux champs

client_id (numéro auto-incrémenté)
client_nom (chaine de caractères)

Deux utilisateurs créent un enregistrement dans cette table EN MEME TEMPS.
La requête est du genre
insert into client (client_nom) values (nomclient)

L'identifiant du client est généré automatiquement. La question est de savoir quand exactement est-il créé?

A- au moment de l'INSERT: auquel cas l'identifiant sera le même dans les deux requêtes.
B- au moment du COMMIT: auquel cas on ne doit pas se soucier des éventuels doublons.
C- "Rien de tout ça. T'es vraiment une chèvre en BDD! Casse-toi!!"

Cela dépend-il des SGBD?

Comment gérer les éventuels conflits (accès concurrentiels)?

Voilà.. J'espère avoir été clair.

Merci d'avance pour vos réponses!

[Xo]

Bonjour, et bienvenue sur le forum,

La lecture de cette article te donnera sûrement des éléments de réponses : Clefs auto incrémentées

[al1_24]

L'affectation de l'identifiant est effectuée au moment de l'INSERT.
Même si la transaction n'a pas encore été validée (COMMIT), le compteur de l'identifiant pour la table est incrémenté ; ce qui fait qu'en cas de ROLLBACK de la transaction il y a des trous dans la séquence des identifiants.
Il n'y a pas de risque d'affecter deux fois un identifiant, parce que la notion de EN MEME TEMPS ne s'applique pas : il y aura quand même séquence des opérations.

[blapointe]

Il n'y a pas de risque d'affecter deux fois un identifiant, parce que la notion de EN MEME TEMPS ne s'applique pas : il y aura quand même séquence des opérations.

Ca contredit l'article précédemment cité...

Ca nous renvoie à la question: "cela dépend-il des SGBD?".

J'ai en effet le souvenir d'avoir créé trois enregistrements dans une nouvelle table, les avoir supprimés et avoir créé un nouvel enregistrement (alors seul dans la table) avec l'identifiant 4. C'est la preuve que, sur ce SGBD du moins, un identifiant est unique et n'est pas réattribué (jamais essayé la réindexation).

[Xo]

Ca contredit l'article précédemment cité...

Je ne crois pas, pourquoi ?

Ca nous renvoie à la question: "cela dépend-il des SGBD?".

Non : le mécanisme d'attribution de la prochaine clé (séquence ou champ auto) est géré par le serveur de données, dès qu'un programme y fait appel, toute tentative suivante d'appel doit attendre que la précédente ait aboutie : impossible donc d'avoir un doublon à ce niveau.

J'ai en effet le souvenir d'avoir créé trois enregistrements dans une nouvelle table, les avoir supprimés et avoir créé un nouvel enregistrement (alors seul dans la table) avec l'identifiant 4. C'est la preuve que, sur ce SGBD du moins, un identifiant est unique et n'est pas réattribué (jamais essayé la réindexation).

C'est normal, le mécanisme pré-cité ne tient pas absoluement pas compte des suppressions, et ne gère donc pas les "trous" : créée 150 enregistrements, supprime-les, le prochain aura un identifiant de 151 ...

[al1_24]

Ca nous renvoie à la question: "cela dépend-il des SGBD?".

C'est le SGBD qui gère ses séquences comme il l'entend...
Exemple : je travaille sur Teradata, SGBD orienté décisionnel et entrepôts de données.
Depuis la version 5, il prend en charge les identifiants auto-incrémentés définis par la norme ANSI.
Lors des opérations de chargements de fichiers dans des tables, donc insertion massive d'enregistrements, le SGBD ouvre plusieurs sessions simultanément et affecte à chacune des paquets de lignes, histoire d'optimiser les traitements en utilisant au mieux son architecture massivement parallèle.
Pour perdre moins de temps à gérer l'identifiant auto-incrémenté, chaque session se voit attribuer une plage d'identifiants au fur et à mesure des besoins.
A l'arrivée, toutes les lignes sont dans la table, affectées chacune d'un identifiant numérique unique mais dont la valeur n'a aucun rapport avec la position de la ligne dans le fichier source.

[blapointe]

Je ne crois pas, pourquoi ?

pour ça :

"'utilisateur A, procède à l'acquisition d'une clef en vue de saisir les données afférentes à Monsieur Gilles LEBLANC. Il lui est attribué la clef 53 puisque la dernière valeur de clef stockée dans la table MaTable est 52. Quelques instants plus tard, l'utilisateur B convient de saisir les informations de Monsieur Pierre LENOIR et se fait attribuer lui aussi une clef. Vous aurez deviné que A n'a pas encore terminé de saisir ses informations et que par conséquent l'utilisateur B se voit attribuer la même valeur de clef que l'utilisateur A, à savoir 53"

Mais bon, tout est clair maintenant. Merci pour vos réponses!!!!

[Xo]

L'utilisateur A, procède à l'acquisition d'une clef en vue de saisir les données afférentes à Monsieur Gilles LEBLANC. Il lui est attribué la clef 53 puisque la dernière valeur de clef stockée dans la table MaTable est 52. Quelques instants plus tard, l'utilisateur B convient de saisir les informations de Monsieur Pierre LENOIR et se fait attribuer lui aussi une clef. Vous aurez deviné que A n'a pas encore terminé de saisir ses informations et que par conséquent l'utilisateur B se voit attribuer la même valeur de clef que l'utilisateur A, à savoir 53

Oui, ça, c'est le paragraphe "3.1. Une fausse bonne idée", la solution qui consiste à essayer de gérer soi-même le prochain identifiant, en lisant les autres valeurs déjà insérées dans la base, rien à voir avec un champ de type auto-incrément ou une séquence

Mais bon, tout est clair maintenant. Merci pour vos réponses!!!!