auto_increment

06 juin 2005, 21:03

Bonjour
comment dans une table mysql peut on savoir la valeur actuelle de l'auto_increment ?
Pour le moment j'utilise

SELECT MAX(colonne auto_incrementée)

mais je ne sais pas si de 1 c'est la meilleur methode de 2 si c'est tres fiable.
Merci
Guy

06 juin 2005, 22:34

Tu as deux manières de savoir le dernier numéro d'un champ auto-incrémenté : tu as cité toi-même la seconde, je ne reviendrai donc pas dessus et tu peux t'y fier.

La première méthode consiste à récupérer cet identifiant lors de l'insertion avec mysql_insert_id()

06 juin 2005, 22:41

Code : Tout sélectionner

SELECT MAX(colonne auto_incrementée)

1. C'est une excellente méthode
2. Elle est parfaitement fiable

Un traitement sur la base en SQL est toujours à préférer à un traitement PHP.

07 juin 2005, 09:10

petit exemple

Code : Tout sélectionner

INSERT INTO table (chaine) VALUES("coucou");
INSERT INTO table (chaine) VALUES("tout");
INSERT INTO table (chaine) VALUES("le");
INSERT INTO table (chaine) VALUES("monde");
INSERT INTO table (chaine) VALUES("gentil");

Code : Tout sélectionner

table (auto_increment, chaine)
1 - coucou
2 - tout
3 - le
4 - monde
5 - gentil

Code : Tout sélectionner

DELETE FROM table WHERE auto_increment=3;
DELETE FROM table WHERE auto_increment=5;

Code : Tout sélectionner

table (auto_increment, chaine)
1 - coucou
2 - tout
4 - monde

Code : Tout sélectionner

SELECT MAX(auto_increment) FROM table

=> retourne 4, alors que l'auto_increment de la colonne auto_increment=5

07 juin 2005, 09:18

joli contre-exemple

en même temps, connaitre la valeur actuelle de l'auto-increment, ça sert à quoi?

A+

Pascal qui sait débloquer les auto_inc en SQL Server

07 juin 2005, 09:25

une solution suggérée par SQLPro :
créer une table des dernières clés générées pour chaque table, sur laquelle tu pourras faire ton MAX()+1 sans soucis car elle ne sera pas affectée par les opérations de suppression

http://sqlpro.developpez.com/cours/clefs/#L3.2

07 juin 2005, 11:10

en même temps, connaitre la valeur actuelle de l'auto-increment, ça sert à quoi?

Strictement à rien.
Ce n'est pas la valeur de l'auto-incrément qui est intéressante,
mais le dernier enregistrement saisi dans la table
(auquel correspond cette valeur de l'auto-incrément)
et je crois que c'est ça que recherche Guy.

07 juin 2005, 14:58

Code:
SELECT MAX(auto_increment) FROM table

=> retourne 4, alors que l'auto_increment de la colonne auto_increment=5

donc le prochain enregistrement aurras comme comme id 6 et pas 5 comme mon code le laissait entendre.
En cas de jointure avec comme champs de reference la colonne auto-incrementée cela pose probleme si on y fait pas gaffe.
(dans le champs de reference de l'autre table jointe si je met la valeur du MAX +1 cela ne corrspondras pas)
Moralité je vais encore utiliser cette methode du SELECT MAX() mais apres y avoir introduit mes variables et avant de les introduirte dans le champs de la table jointe.
Guy[/code]

07 juin 2005, 15:02

Si tu supprimers le dernier enregistrement de ta table, le champ en auto_increment ne reviendra pas en arrière et ne reprendra pas à partir du dernier numéro existant mais du dernier numéro utilisé. Si le champ indque le plus grand à 4 et que le dernier à 5 a été supprimé, le suivant sera à 6 et non à 5 et on ne peut rien y faire sauf peut-être en forçant l'enregistrement du champ à 5 manuellement. (À tester, je n'ai pas vérifié)

07 juin 2005, 15:06

Ce n'est pas une bonne solution de donner des valeurs manuelle à une colonne auto_increment car il y a de très grande chance qu'il y ait conflit au moment ou on vas vouloir reprendre le cours des auto_increment !!!!

De manière générale, il ne faut pas mettre de valeur manuellement dans un champs auto_increment !!!

2 solutions :
- laisse le champs gérer tout seul les valeurs qu'il contient
- enlève le auto_increment et gère toi même les valeurs

07 juin 2005, 15:56

Je vais mettre un bémol là-dessus: mauvaise idée de gérer manuellement un champ de clé primaire: laisse donc faire MySQL. La clé primaire n'est pas une donnée, c'est un point de repère, point barre, il ne faut pas l'utiliser differemment. Ça permet de retrouver rapidement une donnée, de la mettre en relation avec les informations d'une autre table, mais ce n'est pas une donnée en rapport direct avec les données de la ligne correspondante.

Donc, si un champ est auto-incrémenté, c'est précisément pour ne pas à avoir à s'en soucier. Si tu as besoin d'un point de repère qui reflete le nombre d'articles dans l'ordre où ils ont été enregistrés, alors crée un champ supplémentaire en te disant qu'à chaque mise à jour ou modification de la table, il faudra mettre toute la colonne à jour pour chaque ligne si nécessaire.

C'est un peu inutile d«'autant qu'il y a des fonctions de tri qui te permettent de créer un numéro lors du traitement pour affichage, mais c'est un champ calculé que tu crées à la demande: par principe, on ne met JAMAIS de champ calculé dans une base. C'est un peu comme si on mettait une colonne "age" dans une table user. Les valeurs enregistrées dans cette colonne sont fausses dès le lendemain de l'enregistrement.

07 juin 2005, 16:07

Je suis entièrement d'accord avec Cyrano !!!

On m'a toujours apris que dans une table, il fallait un identifiant auto_incrementé clé primaire et qu'il ne fallait jamais le toucher ni l'utiliser autrement que pour faire une clé étrangère !!!!

Cet identifiant doit être entierement invisible à l'écran, on ne doit jamais le modifier ou l'incrémenter !!!!

Ca permet de garantir une certaine intégrité référentielle et ça facilite énormément les modifications car tu as toujours un champs qui ne bouge pas !!!!

07 juin 2005, 16:24

hey les gars, je suis d'accord avec vous, c'est sale de toucher aux auto_increment, mais avec un bemol:
desfois on est obligés de le faire

exemple vécu:
j'ai migré des données de différentes sources (une base access, des fichiers excel). pour les données de la base access,
- soit je laissais l'id en auto_inc et je devais bidouiller (= scripter) pour le retrouver pour les relations dans la suite de la migration (comment garder les relations si on a perdu l'id?)
- soit je gardais l'id et forçait le passage "manuel"/explicite des id
SET IDENTITY_INSERT entreprise ON
...
avant de le remettre en auto_increment:
SET IDENTITY_INSERT entreprise OFF
(sous SQL Server)

conclusion
parfois on peut toucher les id, si c'est la solution la plus adaptée (simplicité, temps de réalisation) mais en général on ne doit pas s'en soucier.

A+

Pascal

07 juin 2005, 16:30

Franchement, entre nous, si le transfert doit être fait régulièrement, c'est un problème de conception !!!!

Ensuite, tu peut créer un nouvel id et récupérer l'ancien dans un champ non auto_increment !!!

Mais je pense que ton exemple est ponctuel et que en aucun cas il ne doit être une excuse pour ne pas appliquer ce que j'ai dit plus haut !!!

Et, pour être en train de transferer et d'adapter des données d'une bdd à une autre en ce moment, je peux te dire que rien n'est impossible et que, même avec de gros traitements, tu peut tout remettre à plat

07 juin 2005, 16:40

Franchement, entre nous, si le transfert doit être fait régulièrement, c'est un problème de conception !!!!

Ensuite, tu peut créer un nouvel id et récupérer l'ancien dans un champ non auto_increment !!!

Mais je pense que ton exemple est ponctuel et que en aucun cas il ne doit être une excuse pour ne pas appliquer ce que j'ai dit plus haut !!!

Et, pour être en train de transferer et d'adapter des données d'une bdd à une autre en ce moment, je peux te dire que rien n'est impossible et que, même avec de gros traitements, tu peut tout remettre à plat

c'était une initialisation, j'ai tout scripté en procédures stockées + lots DTS (trucs pour manipuler les données dans les transferts sous SQL Server).

c'est sur, on peut toujours tout faire, maisle but du jeu c'est de le faire vite et bien, donc j'ai pris cette solution. je pouvais aussi creer des champs en plus, des tables de correspondance...

A+

Pascal

auto_increment

Qui est en ligne