Plutôt une grosse requête multitables ou plein de requêtes séparées ?

WRInaute occasionnel
Bonjour,

J'ai une grosse requête à faire là, qui va chercher sur au moins 6 tables d'un coup. Ca va faire une sorte de gros arbre super touffu.

Je sais pas si c'est une bonne idée. Et ça va être casse-tête. Faisable, mais casse-tête.

Je me demande si je ne devrais pas plutôt faire une requête simple sur une ou deux tables, puis à l'intérieur de la boucle while, refaire une requête avec une nouvelle boucle while dans laquelle je refais une requête.

Qu'est-ce que vous en pensez ?
 
WRInaute occasionnel
Dans des bases de données relationnelles, la solution est souvent de multiplier les tables: tes requêtes spécifiques ne se baserons plus sur des grosses tables mais sur une multitutes de petites.
J'utilise une "gestion commerciale" que j'ai programmé pour moi (elle fait un peu plus, ticket de caisse, déclaration TVA, inventaire, ...) . J'utilise plus de 30 tables ... certaines sont liées en PHP, d'autres pas. J'ai simplement séparé les clients des fournisseurs, les familles de produits des articles, les codes comptables sont créés quand je met un produit en fonction de la famille MAIS, les codes comptables sont aussi repris dans la fiche produit (donc modifiable pour un seul produit). Créere des bases de données, c'est d'abord beaucoup de réflexion.
 
WRInaute accro
Dans mon dernier site perso, pour afficher une liste de prix j'ai des requêtes qui tapent dans plus de 10 tables.
Mais une fois que les relations (ForeignKey, OneToOne, ManyToMany) sont définies dans les models, tout est transparent, même pas besoin de taper la moindre ligne de SQL.
 
WRInaute discret
la réponse m'intéresse aussi en terme de performance...
Avant je ne faisais jamais de jointure et je relançais une requête pour chaque jointure, maintenant j'utilise les jointures, d'après le peu de recherche que j'ai que j'ai les jointures sont mieux niveaux performances sauf certains cas spécifiques
 
WRInaute occasionnel
Salut à vous tous,

patrick_lejeune a dit:
bases de données, c'est d'abord beaucoup de réflexion.
Oui, le problème, c'est que souvent, au fur et à mesure que l'on programme, on se rend compte que ceci et cela peut être fait différemment, ou alors que l'on peut en profiter pour ajouter quelque chose et donc au final, le projet n'est plus ce qu'il était au départ.
Vous allez me dire que je ne sais pas planifier un projet informatique, mais reconnaissez qu'un programmeur qui rend son travail dans les délais prévus, c'est aussi rare qu'un ticket de loterie gagnant.

spout a dit:
Dans mon dernier site perso, pour afficher une liste de prix j'ai des requêtes qui tapent dans plus de 10 tables.
Mais une fois que les relations (ForeignKey, OneToOne, ManyToMany) sont définies dans les models, tout est transparent, même pas besoin de taper la moindre ligne de SQL.
OneToOne, ManyToMany... On en apprend tous les jour (surtout avec spout) ! A part les clefs étrangères, je ne connais rien d'autre.


Mais j'ai peut-être mal posé le problème, en fait. Car je compte utiliser la POO pour ce site (premier essai).
Donc en fait, je vais créer une classe, puis générer des objets (des articles en fait) dont les paramètres seront définis par la variable retournée par l'URL (rien que de très classique).
Par suite, le mieux n'est-il pas tout simplement, pour chaque attribut de l'objet, de faire une requête qui permette d'en définir la valeur ?

Ca me parait beaucoup plus fluide lors de la lecture du script.
SInon, il faut que je fasse une grosse requête, puis dans la boucle while, définir la valeur de chaque variable, je trouve que ça fait grosse boule compact, c'est moche.
 
Discussions similaires
Haut