Salut à tous    
 
Voilà, j'ai une table mysql "educateurs" où, pour chaque modification d'enregistrement, je ne fais pas un UPDATE mais un INSERT INTO afin de pouvoir afficher l'historique des modifications. Grosso modo, ça donne ça :
 
Mise à jour d'un educateur :

 
En gros, à chaque modification, je donne un nouvel ID à l'éducateur et j'indique son ancien ID, puis je rends inactif son ancien enregistrement.
 
Le premier enregistrement qui a été fait pour un éducateur a un ancien_id = 0.
 
On a par exemple les enregistrements suivants :
1, 0, DUPONT, Jean, (données diverses),0
14, 1, DUPONT, Jean, (données diverses modifiées),0
23, 14, DUPONT, Jean, (données diverses modifiées),0
31, 23, DUPONT, Jean, (données diverses modifiées),1
 
Ma question :  
Comment remonter l'historique des modification avec SQL ?
Je pensais faire un LOOP, mais j'arrive pas trop à saisir si le comportement et la syntaxe. Et puis, il me faudrait mettre à chaque fois l'ancien ID dans une variable.
 
Y'aurait bien une solution avec une boucle côté PHP, mais ça risque d'être un peu lourd pour le serveur de base de données...
 
Merci pour votre aide  

C'est quand même pas top comme structure
J'aurais plutôt vu 2 tables :
L'une qui contient les données courantes, l'autre qui contient l'historique. Comme ça, t'as qu'un seul ID pour l'éducateur. Parce que je te dis pas le bazar si cet ID est utilisé comme clé étrangère dans d'autres tables et qu'il faille le changer pour mettre l'ID courant
 
Pour la table contenant l'historique, t'as le choix :
- soit elle a une structure similaire à celle contenant les données courantes, avec en plus, en clé étrangère, l'ID de l'éducateur. Facile pour récupérer l'historique mais grosse duplication de données identiques si très peu ont changé
- soit elle a une structure avec le nom du champ qui a changé (tu peux aussi le représenter par un enum ou une constante de type entier) et la valeur que le champ avait avant le changement + en clé étrangère, l'ID de l'éducateur. C'est un plus compliqué pour reconstituer l'historique mais t'as pas de duplication de donnée

Ah ouais je vois.
 
Effectivement, y a un raté là-dessus.
Ton idée de faire une table historique est bonne. Il va me falloir un script pour récupérer l'existant et le déplacer dans la table qui va bien...
 
Merci pour ton aide.
 
Je reste ouvert à d'autres idées.

je confirme que c'est comme ça qu'il faut faire. en rajoutant une date de mise à jour si besoin.

Effectivement, j'ai oublié de préciser qu'il fait un champ date, voire un champ date/heure mais bon, quand on parle d'historique, ça implique une notion d'horodatage en général...

oui pas habitué à MySQL, en oracle un champ date contient forcément la date et l'heure

Okay.
 
Bon, je vais essayer de réorganiser mon bazar.
 
Merci à vous