Discussion :

[vsavoir]

Bonjour les amis,

Je voulais savoir le mécanisme de gestion interne (par le SGBD) des clefs des tables.
En fait ce qui me gêne c'est cette histoire qu'une clef est utilisée une fois et ne peut pas être réutilisée après. Donc ma question est la suivante:
Si la taille de la variable contenant la clef est de 1octet, alors que se passe-t-il lorsque on arrive à la dernière valeur possible sur 1octet. Le système reprend-t-il les nombres non utilisés ou il ne peut plus générer de clef et donc ce cas il renvoit une erreur de dépassement?

Merci pour votre aide

[qi130]

Avec, une clé d'1 octet, tu peux gérer au plus 255 occurrences, 1 point c'est tout.

Il faut garder présent à l'esprit qu'une clé sert avant toute chose de discriminant: elle permet de différentier 2 occurrences, même si ces occurrences sont très proches.

L'exemple type sont des jumeaux: mêmes nom de famille, date de naissance, etc...
=> pour la famille, c'est le prénom qui sert de clé
=> pour les autorités, c'est le n° de S.S (il contient le rang de naissance)

Pour en revenir au SGBD, il est clair que 2 enreg ne peuvent avoir la même clé:
1/ d'abord parcequ'il serait incapable de restituer 1 enreg à partir de cette clé (en fait, il peut, mais ce sera tjs le même enreg: au 1er trouvé, il arrête de bosser)
2/ ensuite parceque peut se poser le pb des clés étrangères : nos jumeaux vont avoir des enfants, et pour indiquer la filiation on peut vouloir utiliser le n° S.S du parent: si on demande "quels sont les enfants d'un des jumeaux, on récupère tous les enfants des 2 jumeaux !
3/ d'autres soucis en cascade : UPDATE/DELETE => comment indiquer le décès d'un des jumeaux ?
4/ déclarer 1 clé, ça donne implicitement 1 index sur la colonne "clé"=> le classement des valeurs est maintenu dans l'ordre (croissant ou décroissant) par le SGBD: si on dispose de 2 clés de valeur=1, laquelle est supérieure à l'autre ? si (comme) tu ne peux répondre à cette question, pourquoi le SGBD pourrait-il le faire ?

J'espère avoir répondu à tes interrogations.

[vsavoir]

Je te remerci d'avoir pris le temps de réponde à ma question.
Pour plaisanter: puisque ta réponse n'est pas la bonne alors je considère que ma question est mauvaise. .
En fait, je comprend bien le principe de clef (unicité). Comme tu me la fait remarquer avec 1 octet tu peux avoir 255 clef seulement, mais c'était juste pour l'exemple. Bon je reformule ma question:
suppons que la la dernière clef attribuée par le SGBD est 255, alors quelle clef attribuera-t-il à un nouveau enregistrement? Est-ce qu'il reprend les clefs qui ont été supprimé (entre 1 et 255) et donc qui ne sont pas utilisés ou bien il ne peut plus attribuer de clef?

Merci.

[qi130]

Tu sembles évoquer l'auto-attribution par le SGBD d'un numéro faisant office de clé ? (avec auto-incrément ?)

[SQLpro]

1) après 255 il générera une erreur et plus d'insertion
2) on utilise en général une clef basée sur l'entier de taille du mot processeur, soit 32 octets et cela pour des raions de performances (donc 4 milliards 300 millions de clefs possibles)
3) en 32 bits, à raison d'une insertion par seconde sans jamais s'interrompre, il te faudra 136 ans pour générer cette erreur.
Dans le cas improbable ou tu arrive à la fin de tes clefs, tu peut combiner une deuxième colonne. Dans ce cas, tu disposera de quelques 600 millirads d'années avant d'épuiser toutes mes combinaisons...

Enfin, principe de base UNE CLEF CONSOMMÉ NE DOIT JAMAIS ÊTRE RÉATTRIBUÉ...

Que se passe t-il si tu doit remonter une sauvegarde partielle ?

A lire :
http://sqlpro.developpez.com/ClefsAu...ClefsAuto.html

A +

[vsavoir]

Merci a tous.

[dcollart]

Bonjour,

une erreur est produite si on laisse le soin au SGBDR de choisir lui même la clé. Par contre si dans notre INSERT on précise comme clé la valeur
d'une qui a été supprimée, alors l'INSERT se produit correctement au
risque de perdre l'intégrité des données.

Bonne journée.

[dcollart]

Bonjour,

Petite précision. Dans le cas où on précise la valeur de la clé dans
l'INSERT, le SGBDR attribuera la valeur maximale possible à la clé
si la valeur saisie est plus grande que la valeur maximale permise.
La valeur maximale possible ne sera attribuée que si elle n'est pas
déjà utilisée.

exemple d'une clé codée sur un SMALLINT(1) :

Si dans notre INSERT, on précise la valeur 100 000 pour la clé alors
le SGDR attribuera la valeur maximale 32 767 (si elle n'est pas déjà
utilisée).

Face à ce phénomène, il est important de s'assurer que les clés des
tables liées par une relation (clés primaires et étrangères) soient du
même type.

Pour revenir à notre exemple.....

Supposons que notre transaction doit insérer un enregistrement dans
une table dont la clé primaire est codée sur un SMALLINT(1) puis insérer
une enregistrement dans une autre table dont la clé étrangère est codée
sur un INTEGER (ces deux tables étant liées par une relation).

L'insertion de la valeur 100 000 pour la clé primaire donnera 32 767.
L'insertion de la valeur 100 000 pour la clé étrangère donnera 100 000.

Résultat : clés primaire et étrangère différentes => problème d'intégrité
des données.

Bonne journée.