Dans une base MySQL, gérée par une page en PHP, j'ai des champs du genre :
result_1, recap_1, result_2_1, result_2_2, result_2_3, recap_2, result_3, recap_3, result_4, recap_4, result_5_1, result_5_2, result_5_3, result_5_4, result_5_5, result_5_6, result_5_7, recap_5, result_6, recap_6, etc.
 
Ces champs contiennent des réponses à des questions à choix unique ou à choix multiples, plus une zone de texte associée à chaque question.
 
Si je supprime une question, par exemple la 3e, je supprime result_3 et recap_3. Faaaaaacile !!
 
Mais je dois aussi renommer les autres champs (sinon le programme ne les retrouve plus) pour qu'ils deviennent :
result_3, recap_3, result_4_1, result_4_2, result_4_3, result_4_4, result_4_5, result_4_6, result_4_7, recap_4, result_5, recap_5, etc.
 
Si je procède avec une boucle qui traite champ par champ, vu le nombre de champs concernés, je peux obtenir un time out aléatoire, et l'appli se plante. De toute façon, c'est trop long.
 
Que puis-je faire de mieux qu'une instruction du genre :
 $sql_change = "ALTER TABLE `".$table."` CHANGE `result_".$numQuestion."_".$reponse."` `resultat_".$nouveauNum."_".$reponse."`";
 
Il doit bien être possible de fixer un index de départ (dans mon exemple, c'est = 4) et trouver une instruction plus puissante où tous les `result_".$numQuestion."`, `result_".$numQuestion."_".$reponse."` et `recap_".$numQuestion."` devront passer à ($numQuestion - 1)  si dans le nom du champ $numQuestion est >= 4.
 
Mais laquelle ???

J'ai pas compris grand-chose, et apparemment je suis pas le seul (3 jours sans réponse).
 
Par contre, je peux te dire que si tu es amené à renommer ou supprimer des champs, c'est que tu n'utilises pas la bonne technique.
 
Ce genre de schéma devrait normalement suffire :
ID (int) | N_de_la_question (int) | Reponse (bool) | Texte (text)
Avec, peut être, une 2ed table pour stoquer les questions, dans ce cas N_de_la_question sera une foreign key.

Il ne s'agit pas de questions avec un choix de réponses figées. Le questionnaire évolue en permanence. Cette évolution est même le principal but de l'exercice.
 
Je stocke les choix de réponses dans une table. Ces choix de réponses sont corrélés avec un fichier des questions et réponses possibles, comme dans un QCM.
Le problème vient de ce que les questions et réponses ne sont pas définitives. Une question peut être ajoutée, modifiée ou supprimée (ou déplacée).
A tout moment, je dois pouvoir extraire les choix d'un participant au questionnaire, sans perdre les réponses déjà faites si le questionnaire a évolué entre temps.
 
Exemple : Fichier du questionnaire :
"La question 1" (choix multiple)
"La réponse 1_1"
"La réponse 1_2"
"La réponse 1_3"
"Le commentaire 1"
"Ma question 2" (choix unique)
"Ma réponse 2_1"
"Ma réponse 2_2"
"Mon commentaire 2"
 
Table des réponses faites par les participants :
nom, motpasse, email, reponse_1_1, reponse_1_2, reponse_1_3, commentaire_1, reponse_2, commentaire_3
 
ex :
"Toto", "motpassetoto", "email@toto", "0", "2", "0", "mon commentaire", "2", "autre commentaire" (Toto a choisi les réponses 1_2 et 2_2)
"Titi", "motpassetiti", email@titi", "1", "2", "3", "sans", "1", "" (Titi a choisi les réponses 1_1, 1_2, 1_ 3 et 2_1)
etc. (une ligne par participant).
 
Si j'intercale une nouvelle question 2 (4 réponses possibles en choix multiple par ex.)
"Ma question 2" devient "Ma question 3"
"Ma réponse 2_1" devient "Ma réponse 3_1"
"Ma réponse 2_2" devient "Ma réponse 3_2"
"Mon commentaire 2" devient "Mon commentaire 3"
 
Et donc la table des réponses faites devient par exemple :
nom, motpasse, email, reponse_1_1, reponse_1_2, reponse_1_3, commentaire_1, reponse_2_1, reponse_2_2, reponse_2_3, reponse_2_4, commentaire_2, reponse_3, commentaire_3  
 
ex :
"Toto", "motpassetoto", "emailtoto", "0", "2", "0", "mon commentaire", "0", "0", "0", "0", "", "2", "autre commentaire" (les réponses 1_2 et 2_2 sont devenues 1_2 et 3_1, Toto n'a pas répondu à la nouvelle question 2)
"Titi", "motpassetiti", emailtiti", "1", "2", "3", "sans", "0", "0", "0", "0", "", "1", "voilà" (les réponses 1_1, 1_2, 1_3 et 2_1 sont devenues 1_1, 1_2, 1_3 et 3_1, Titi n'a pas répondu à la nouvelle question 2)
etc.
 
Les personnes ayant déjà répondu peuvent rappeler le questionnaire, retrouver leurs réponses (les modifier au besoin), et répondre à la nouvelle question.
 
Une autre façon de voir le problème aurait été d'attribuer un clé unique à chaque réponse
Une table de participants :
"nom", "motdepasse", "email"
 
Un table par réponse :
Reponse 1_1 :
"toto", "0"
"titi", "1"
etc.
 
Réponse 2_1 :
"toto", "2"
"titi", "2"
etc.
 
Et ainsi de suite.
Je ne peux pas vraiment regrouper les réponses possibles à une question, car le nombre de réponses peut aussi évoluer, donc je retombe sur le problème initial.
 
Avantage : je ne renomme rien.
Inconvénient : beaucoup plus difficile de s'y retrouver à la lecture directe des tables. La moindre extraction nécessite de ne pas se paumer dans les index. Les tables peuvent devenir très nombreuses.
 
Je me complique un peu la vie en intercalant des champs alors que les laisser en bout d'enregistrement marcherait aussi bien. (J'aime bien pouvoir relire directement une table). Mais s'il est possible de renommer un champ en incrémentant l'indice qu'il contient sans faire une instruction par champ (pénalisant en temps), alors il serait dommage que je m'en prive.
Sinon, il faut faire une table de traduction pour dire que reponse_2_1 est en fait la réponse 1 de la question 3, etc. Je sais, l'informatique sert à se débarrasser des problèmes en les rendant transparents, mais l'usine à gaz qui en résulte n'est pas triste pour celui qui doit repasser derrière.
 
A tout instant, si je décide que le questionnaire n'a plus à être modifié, les tables sont propres et lisibles. Le problème, c'est la gestion avant cette mise au point finale.
 

J'ai une partie de la réponse :
Si je boucle sur chaque champ, avec donc une requête à chaque fois, ça prend un temps fou.
Je peux inclure plusieurs champs dans une même requête, construite au fur et à mesure dans une boucle, et donc lancer une seule fois la requête. C'est beaucoup plus rapide. La difficulté était de trouver la bonne syntaxe.