Discussion :

[Invité]

Bonjour à tous !
J'ai une table dans une base de données MySQL.
L'un des champs de cette table, appelé 'id' est auto-incrémenté.

Il se trouve que lorsque je supprime une entrée de la table, puis que j'en ajoute une, l'id de cette dernière ne prends pas la valeur laissée libre par la suppression.

Exemple :
1 truc
2 machin
3 chose

je supprime 2 machin :
1 truc
3 chose

j'ajoute bidulle :
1 truc
3 chose
4 bidulle

Est-il possible que, dans l'exemple ci-dessus, l'id de bidulle prenne la valeur 2 au lieu de 4 ?
Comme ce n'est pas un champ visible par l'utilisateur, ma question n'a pas une grande importance... Elle éveille néanmoins chez moi beaucoup de curiosité

Merci d'avance !
Axel

[Alain Defrance]

Bonjour,

Ce comportement est totalement voulu. Ces sauts dans l'incrémentations sont necessaires pour eviter des problèmes dans certains cas. Je t'invite a lire cet article qui en dis plus.

[jnore]

Si tu veux gérer les trous, il a falloir programmer un trigger.

[Alain Defrance]

Si tu veux gérer les trous, il a falloir programmer un trigger.

C'est de toute évidence une mauvaise pratique de vouloir "boucher" ces trous ...

[jnore]

Personnellement sur une clé unique serialisée, je ne pratique jamais, j'essaie juste d'adapter à son besoin.
Je ne suis pas pour cette démarche.

Pour autant c'est un bon exercice !

Une seule fois, j'ai eu à pratiquer le rebouchage. C était sur une appli comptable sur laquelle devait paraître un numéro unique sur les débits.
Mais en la circonstance, ca n'était pas sur la clé primaire.

Cdlt

[SQLpro]

Que ferez vous si dans une sauvegarde existe le client 44 que l'on supprime après. Puis on ré attribue le jeton 44 à une autre client et enfin on vient vous voir parce que le client 44 supprimé l'a été par erreur et que vous devez le récupérer de la sauvegarde ????

C'est pourquoi par principe ON NE RÉ ATTRIBUE JAMAIS UN JETON (auto incrément) CONSOMMÉ !

A +

[Invité]

Oups...
J'avais complètement oublié ce post !
Je suis vraiment désolé.

En ce qui concerne ma question, si j'ai bien compris, premièrement ce n'est pas facilement configurable dans phpmyadmin et deuxièmement c'est très déconseillé.

Merci pour vos réponse
Encore désolé et à bientôt !

Axel

[Alain Defrance]

si j'ai bien compris, premièrement ce n'est pas facilement configurable dans phpmyadmin

Ce n'est pas que ce n'est pas configurable, c'est que ca n'éxiste pas, et ce n'est pas pour rien

[Invité]

Ah en fait, il me reste une question !

Pour une base de données qui ne contient pas trop de champs (une centaine par exemple) mais dont les champs sont supprimés et ajoutés très souvent dans la base, il va bien arriver un moment où le nombre incrémenté dépassera le domaine de l'attribut.
Et selon moi pour une base de cette taille, un BIGINT est un peu lourd...

Y a-t-il une solution ? Sachant que l'administrateur n'a pas le temps de supprimer l'attribut et de le recréer (dans l'hypothèse que ça réinitialiserait le compteur d'incrémentation)...

[fally]

d'abord, je fais mien le post de SQLpro

...les champs sont supprimés et ajoutés très souvent dans la base...

dans ce cas, formate toi-même ta clé, on n'est jamais à l'abri

[soazig]

Bonjour,

ui ne contient pas trop de champs (une centaine par exemple) mais dont les champs sont supprimés et ajoutés très souvent dans la base

Parlerais-tu de lignes? et non de colonnes?
A+
Soazig

[Invité]

Bonjour,

Parlerais-tu de lignes? et non de colonnes?
A+
Soazig

Oui je parle effectivement de ligne, mais je pense que fally possède la meilleure réponse qui existe : gérer soit même l'incrémentation, avec par exemple un comblage des trous automatique si on dépasse un certain nombre. Après, comme le montre SQLpro avec son exemple, tout dépend de ce qu'on veut faire...

Bon je ne pense pas en arriver là un jour, mais c'est quand même bon à savoir !
Merci beaucoup !

A bientôt,
Axel

[SQLpro]

il va bien arriver un moment où le nombre incrémenté dépassera le domaine de l'attribut.

Avec un INTEGER cela limite le nombre de lignes effectivement créées et supprimées à 2 milliards.
Sachez cependant qu'a raison d'un insertion par seconde dans la table, il vous faudra 30 ans pour épuiser ce milliard de nombres. De plus vous pouvez commencer par - 2 ^ 31 ce qui revient à doubler le nombre des clefs et vous laisse donc 60 ans. D'ici là, j'espère que la retraite se fera avant 80 ans !

A +

[Invité]

Avec un INTEGER cela limite le nombre de lignes effectivement créées et supprimées à 2 milliards.
Sachez cependant qu'a raison d'un insertion par seconde dans la table, il vous faudra 30 ans pour épuiser ce milliard de nombres. De plus vous pouvez commencer par - 2 ^ 31 ce qui revient à doubler le nombre des clefs et vous laisse donc 60 ans. D'ici là, j'espère que la retraite se fera avant 80 ans !

A +

C'est vrai que vu comme ça...