Voila j'ai une base de donnée sur mysql.
 
Mais j'ai un soucis. J'aimerais que lorsque je supprime un enregistrement, l'enregistrement qui suivra (un nouveau donc) prendra sa place. PLus explicitement son id soit repris. Alors que pour le moment chaque numero n'est utilisé qu'une fois meme si il n'existe plus.
 
Merci de vos reponses.

impossible ( a ma connaissance ) avec un champ en auto_increment ( ce qui est souvent le cas des cles
il faut le gerer a la main  
 
par exemple :  une table contient les idnex effacés ( donc dispos )  
quand tu veux faire un insert > tu regarde si la table d'index effacée est vide  
Si oui tu pioche un index  
si non tu genere un nouvel index

oulalal on se calme.... :-D
 
Comment on fait pour voir l'index effacé. J'utilise easyphp. Et quand je gere mes dbs ben je voient les index effacées je ne vois que les enregistrements. Y a t-il donc un moyen/ fonction qui peut recupérs la premiere clé effacé trouvé ?

Tu recupere la liste des id et tu la parcours pour voir lesquels manques

 
efficace , mais un peu gourmand

vi ca risque d'etre tres gourmand sur 4000 enregistrement. Faudrait un moyen que je recupere a partir du 1 er enregistrement l'index qui me manque ? J'ai un logiciel de gestion de bibliotheque qui fait ça a mon boulot, donc il doit bien y avoir un moyen que j'y arrive aussi j'espere.
 
Merci de votre aide

 
Comme toutes les operations de recompactage ... D'ailleurs je vois pas a quoi ça peut lui servir de faire ça ... En general ce genre de besoin nait d'une mauvaise conceptualisation du projet

merci du compliment.... c'est juste que je veux que ma fiche correspond a un livre avec un numero unique ainsi chaque livre a inscrit a la 1ere page ce numero. Ce numero me sert pour les prets. Je tape le nom de l'emprunteur et le numero du livre et paf le pret est effectué. Donc si il m'arrive de faire une erreur de saisie et que j'ai besoin de supprimer une fiche j'aimerais pouvoir utiliser encore ce numero unique.  
 
Bref evite de juger mon travail s'il te plait et donne plutot un coup de main. Merci

Désolé mais la c'est ta structure qui a un probleme. Si tu supprimes une fiche, pas grave, l'ID sera supprimé avec et on repartira avec le suivant.. Il faut pas te dire "zut, si je laisse des trou dans l'id ca sera lent et je serais plus vite limité en nombre" , ce genre de probleme n'apparait eventuellement que sur des masses de données assez pharamineuses, dont tu es tres tres loin

cela ne vient pas d'un soucis de lenteur mais que chaque livre a ce numero inscrit et doivent se suivre. Si par malheur je supprime un livre (numero 1042) et que je doive le re-rentrer il devra obtenir le meme nombre car c'est celui sur le bouquin.Je me vois mal le raturé. apres je peux pt-etre creer un champs a part qui differe de l'index mais le hic estle meme : comment faire pour retrouver un numero qui n'est pas dans la suite (1-2-3-5 par exemple ici trouver que le numero a mettre c'est le 4) ?

La methode "bourrine mais qui marche" , c'est de créer une table avec l'id de tes livres en autoincrementable, et l'id dont il est question ici. Si tu te loupes tu flingues une ligne de la table qui contient un id mais pas celui de la table des livres, il te suffira d'en remettre un neuf par la suite

ouais c'est vrai que ca fait tres bidouille mais je ne peux exclure cette solution. Je me la garde sous le coude en attendant un autre solution si il y a . En tout cas merci de ton aide et j'attends d'autres avis si il y a ...

En tout ca l'idée de recompacter la table c'est a exclure tout de suite, c'est le genre d'operation tres lourde pour la base.

recompacter ca redonne un nouvelle index ? Du coup meme si c'etait pas lourd ca n'irait pas dans mon cas car il decalerait les index nan ?

Perso je garderais 2 'index'...un interne à la base, en autoincrement, et un second qui apparait sur les bouquins...

 
C'est la version propre de ce que je lui ai proposé, mais ca l'obblige a faire un minimum de calculs .. Alors qu'en ayant 2 tables non .. mais je suis d'accord sur le fait que ta solution est bien plus optimisée

mais comment faire pour savoir quel numeo manque dans cette seconde index ? une boucle qui verifie que les nombres se suivent jusqu'au fameux numero ? ca me parait lourd nan ?

Bein c tt le probleme de ton systeme... L'architecture serait a revoir parceque sinon toute solution est lourde

Tu dois pouvoir trouver le premier non utilisé en une requête, non?

Abon? Et comment qu'on fait? Ca m'a toujours interessé ..

Bah un truc du style :
 
select min(a.indice + 1) from table a where not exists (select b.indice from table b where b.indice = a.indice + 1)

Et b.indice c'est quoi?

 
Bah b c'est l'alias de la table dans la seconde sous-requête...il faut 2 instances de la table différentes pour pouvoir travailler, là...

En gros, je demande à selectionner le plus petit indice (+1) tel que (indice+1) n'existe pas dans la table...

Oui ca je l'ai compris, mais que contient la table b ?

 
'table' c'est le nom de la table, là... a et b ne sont que des alias!

a oui merde j'avais loupé le table a et table b ...

alros table a correspon a la table avec mes id auto-incrementé et table b c'est celle qui correspond au numero des bouquins c'est ça ?
 

Non c'est pas ça, relit la requete une 2ème fois (chose que j'aurais du faire avant d'ouvrir ma gueule )

('table' comme nom de table pour mon exemple c'était p-e pas une bonne idée, en fait...)

nan aurait fallu mettre table1 ou tablePrincipale ou qqch du genre .. Parceque la on peut se dire que table designe 2 trucs differents

oki je vous remerci de votre aide. Je teste ça demaiin et vous tiens au courant...

 
ca vient peut-être du format de fichier, mais j'ai toujours vu MySQL reprendre justement les trous ! (chose que je n'aime pas du tout d'ailleurs)