Discussion :

[f-demu01]

Salut a tous,
j'ai un léger problème concernant la fonction last_insert_id. J'ai une table avec un champ table.id en auto_increment. Dans cette table il arrive que je supprime des éléments "au hasard" (pas forcément les derniers rentrés). Or, je voudrais que ce champ id soit ré indexé automatiquement après la suppression d'un tuple (histoire de pas avoir un index de 1024 alors que j'ai 2 enregistrements). Et ce sans __trop__ faire pagayer la DB
Est-ce que c'est possible?

[vanquish]

Ce n'est à la fois pas possible, mais pas souhaitable et probablement sans intérêt.

Je ne comprend pas bien pourquoi tu veux faire cela.
L'index ne contiendra que les entrée réellement présente dans la table.
Si, suite à des supressions, tu n'as plus que les enregistrements avec les id 7 et 820 dans ta tables, tes indexs quelqu'ils soient n'auront que 2 entrée - pas plus.

De plus le but d'un id unique et auto-incrémenté c'est qu'il deviennent l'empreinte digital de l'enregistrement .
On peut ainsi stocker cette référence dans une autre table, parce que cette référence est fiable et immuable.

Renuméroter les primary key d'une table, ce serait comme si on te changeais ton no de sécu à chaque fois que quelqu'un meurt.
T'images le chantier quand tu auras à gérer ton nouveau numéro et tous tes anciens numéros en fonction de la date des opérations.

Bref renuméroter une clé primaire ; cela n'a pas de sens.


Pour que ta renumérotation soit possible, il faudrait que le champs soit non auto-incrémenté.

[f-demu01]

D'accord, je vois le truc.
En fait, je suis en train de monter un site Web, dans lequel les utilisateurs peuvent ajouter des photos. Or pour simplifier au maximum l'administration de ces photos, je les renomme à la volée en me servant de cet id. Mais tu as mis le doigt sur qqchose à laquelle je n'avais pas pensé ( ): si je supprime un element et que je reindexe cet id, alors les photos ne correspondront plus aux bons items... Bravo bel esprit



Il parait qu'on file des palmes aux gens comme moi...