Version imprimable
Bsr a tous
SVP j'aimerai avoir la syntaxe sql qui permet de reinitialiser l'auto-increment apres avoir fait une mise a jour sur une table
Exp: si jai comme clé les valeurs allant de 1 à 5 et apres supression de l'enregistrement ou la clé est 3 il faudrai que l'enregistremnt de clé 4 ait maintenant la clé 3.......
ça sert à rien. Une clé artificielle ne doit pas avoir de sens intrinsèque.
sinon update, ça marche bien.
si tu as besoin de numéroter tes lignes, il faut les compter
Bonsoir.
Voici un exemple qui pourrait te servir : soit une table nom_table (id_table)
En espérant t'avoir aidé,Code:
2
3
4
5
6
7
8
9
10
11
12
Idriss
juste pour polémiquer,
une colonne auto-increment c'est une clé primaire.
une clé primaire est souvent utilisée pour faire des clés secondaires.
modifier les clés primaire c'est soit
- perdre le lien avec les clés secondaires (MyISAM par exemple) (par exemple avoir des clés secondaire qui n'existent plus dans la clé primaire)
- encore plus vicieux créer décaler les clés secondaires par rapport à la clé primaire, c'est à dire faire une salade de donnée.
- s'offrir le luxe de réécrire toute les clés étrangères (à condition d'avoir ON UPDATE CASCADE activé et INNODB ) et là en fonction de la taille de la base de donnée et du nombre de table, on peut faire un déni de service sur une base uniquement en provocant des suppressions dans la base.
Quel est l'intéret? merci de rayer la mention fausse.
- on est arrivé à max Autoincrement, ya des trous, on compacte.... j'imagine aussi qu'il y a une quantité de données telle qu'il faut essayer de trouver quelque chose d'autre (genre est-ce qu'il n'y aurait pas des lignes à archiver en même temps). de toute façon les temps vont être dur parce que cette solution n'est que provisoire.
- ça fait du bien à l'administrateur de la base de savoir que l'enregistrement id = 100 est le 100ieme enregistrement et non le 27e. Si c'est bien pour la tête du DBA d'accord, mais c'est d'aucune utilité, vu que pour avoir le nombre d'enregistrement il suffit de savoir faire un COUNT() en SQL et que tous les moteurs de bases de données gardent des stats simplissimes comme ça en cache.
Maintenant prenons le cas d'un blog sur le web. Si un article est identifié par son numéro d'enregistrement dans la base de donnée et que ce numéro est présent dans l'url permettant de lire l'article (cf les url de ce forum pour ce faire une idée) , vous allez perdre google en changeant les url des articles parce que vous avez renuméroté ceux-ci. Et vous allez casser les favoris de vos visiteurs, ce qui est peut-être pire.
Bonsoir.
C'est pour ça que j'ai mis en commentaire "ce qui n'est pas toujours souhaitable" pour la seconde requête.
En effet, il faut veiller a respecter les contraintes d'intégrité référentielle et cela peut engendrer, dans certains cas, d'autres problèmes comme l'exemple du blog que vous avez soulevés (problème au niveau du référencement mais aussi des liens vers articles, etc), étant également développeur web, j'en suis parfaitement conscient ;) ... mais après tout dépend du contexte.
Cependant, la troisième requête garde son utilité car elle ne modifie aucune occurrence (donc pas de problèmes au niveau des contraites ni du référencement ou autre dans le cas d'un site web, etc) tout en évitant les trous pour les prochaines entrées (ce qui optimise la table).
Cordialement,
Idriss
P.S : même si la plupart du temps on applique l'auto_incremente sur un champ primary key, rien n'oblige un champ autobincrémenté a être clef primaire. Il faut quand même distinguer ces deux notions ;)
Citation:
Envoyé par ok.Idriss
en effet, j'y avais pas pensé. merci pour le tuyau.