c'est quoi selon les spécialistes de la chose, la meilleure méthode pour insérer par INSERT TO dans une table le  résultat d'une recherche effectuée via un formulaire de 12 tableaux, affichant six variables en réponse de résultats ( donc 12 * 6 = 72 )

Salut, tu veux dire une seule requête pour 72 champs ?
Une requête sera plus rapide que 12.
à+

Oui, ensuite pour réinterroger, je ferais un lien cliquable sur la valeur du premier champ par exemple pour faire dégringoler tout le reste....
Et c'est effectivement la rapidité/légéreté du boulot pour le serveur que je cherchais, j'avais oublié de le préciser !!
Je te remercie

Bonjour, En effet, ca sera plus simple de gerer 1 table avec 73 colonnes que 12 tables de 7 colonnes (avec les indexes), car sinon tu devras faire beaucoup plus de requetes ou alors les compliquer (INNER JOINT, etc...) Pour la charge serveur, ca me parait clair aussi que ce sera moins gourmand, mais pense juste, quand tu fais un select à ne pas utiliser : SELECT * mais : SELECT champs1, champs2 sans quoi, là, tu auras de jolies pertes de performances (50 résultats * 72 champs * le nombre d'utilisateurs simultanés, ca peut ralentir un peu) Le seul défaut, c'est si tu utilise phpmyadmin ou autre, ou là ce sera un peu plus long à faire des recherches manuellement. Sinon, tu seras entièrement gagnant. @+ PS: N'hesite pas à valider la réponse de Evangun

Yop...,

quand on tâche d'optimiser, on ne s'arrête pas à 1 requête.
Tu vas en faire quoi, de ces champs ...?

Je te donne un exemple simple et bête :

j'ai sur mon site des utilisateurs avec leurs coordonnées.
Ils sont affiliés à 1 revendeur.
Chaque revendeur a 1 à n spécialité.

j'ai un formulaire que mon utilisateur remplit avec toutes ces infos...
Que faire ?
Une table utilisateur, avec tous les champs , y compris le revendeur, son nom, ses coordonnées, les spécialités...?
Oui mais moi, je veux aussi que mon utilisateur, sur le site, puisse consulter les revendeurs, voire chercher les utilisateurs qui ont tel ou tel revendeur, ou qui utilise telle ou telle spécialité (de part leurt revendeur).
Si j'ai 1 table...avec tous les champs, quand je fais mes SELECT pour la recherche, je me tape toute la table utilisateur, pour chercher LA spécialité ou LE revendeur auxquels ils sont affiliés.
Alors que si j'ai une table revendeur, une table spécialités, et une table de jointure revendeurs/spécialités, mes SELECT seront nettement plus rapides et efficaces.
Et je ne parle même pas des mises à jour...

C'est un exemple bateau hein, car là ça semble évident.
Mais quand même, réflêchis bien à toutes les implications...

Salut,

juste un truc qui m'a interpelé : "Une requête sera plus rapide que 12."

Pas forcément, tu peux avoir une seule requête très lente contre 12 qui au total sont plus rapides. C'est pas la quantité de requêtes qu'est importante, c'est leur qualité :)

Après une requête très rapide c'est toujours mieux que 12 requêtes rapides :)

---

• Entraide, dépannage et vulgarisation informatique : Mon site de vulgarisation informatique

"Après une requête très rapide c'est toujours mieux que 12 requêtes rapides :)"

Dépend du delta entre "très rapide" et "rapide"... ;-)

Oui, je parlais de la même requête coupées en 12 morceaux

Oui, intéressant ta réflexion !!

En fait moi il s'agit de composés d'un produit

Donc ce qui compte c'est le nom du produit,
Si je comprend bien ta suggestion, il vaudrait mieux que je stocke à part mes id_users avec le nom des produits qu'ils ont en charge, puisque c'est celà qu'ils auront comme lien cliquable ensuite. Donc c'est l'id_produit, qui ira chercher les composés ( les fameux 12 * 6 variables )

J'ai tout compris ?  aie aie aie !!!! lol !!!

"Dépend du delta entre "très rapide" et "rapide"... ;-)"

Si t'as une seule requête plus rapide que 12, tu vas pas en faire 12, ou alors y'a un problème quelque part ^^ (dans le code ?) Pourquoi ne pas faire une seule requête plus rapide et s'embêter avec 12 ?

---

• Entraide, dépannage et vulgarisation informatique : Mon site de vulgarisation informatique