PHP|Débutant :: Forums

Tout faux, les tables n'ont pas de champs mais des colonnes, si ta requête comporte vraiment des étoiles sur le site c'est contre-productif pour soulager le serveur.

En fait, vu que les jointures se font toutes vers la table recettes, il n'y a pas de raison qu'il te retourne plus de lignes que celles de la table qui comporte le plus de liaisons vers recette_id = 150, au passage, vu que recette_id est probablement numérique (j'espère même en auto-increment dans la table recettes) il n' y a pas lieu d'en encadrer la valeur avec des quotes ,'.
Cela dit, ça n'explique pas ce nombre conséquent de lignes retournées. Là on dirait qu'il fait un produit cartésien de toutes les jointures, bizarre.
Tu devrais essayer ta requête avec une seule jonture, puis deux, puis trois, etc. pour voir à partir d'où ça commence à déraper.

Peut-être qu'en l'occurrence le multi-requêtage n'était pas une si mauvaise idée que cela. L'information qu'il faut quand il faut  (remember, just keep it simple, stupid.

Où as-tu pêché cette ânerie ?

Bien entendu, toutes les colonnes visées par le ORDER BY sont indexées dans les tables, n'est-ce pas ?

Bonjour,

Si vous me permettez, pour commencer, voici ce que je dirais en introduction à ma réponse car vous m'en donnez l'occasion.

Vous donnez la définition d'un site qui fonctionne mais qui n'est pas opérationnel. C'est la différence entre ceux qui sont professionnels et les amateurs qui pensent pouvoir faire un site tout seul. Mais dans ce contexte le plus souvent, tout fonctionne bien tant que vous êtes tout seul et votre famille à venir le contempler...

S'il est relativement simple de faire un site qui fonctionne (et encore cela dépends, cela reste très relatif), il en est tout autre de faire un site performant capable de supporter une certaine charge "sans broncher". Tout simplement car cela doit se prévoir le plus souvent dans l'architecture même du site en fonction de ses contraintes de production et ses spécificités métier.

Mais il faut que vous ayez conscience que professionnellement parlant, en ce qui me concerne, il m'est complètement impossible de vous répondre sans faire un audit détaillé de votre site. Voici quelques questions pour vous aider à comprendre pourquoi :

De quel traffic parlez-vous quantitativement parlant? Quel est la charge que votre site doit être capable de supporter? Ce traffic correspond-t-il à un pic d'utilisation, et si oui quel est-il?

C'est tout sauf une définition de structure de votre base de données, le résumé d'un aperçu serait plus juste.
Il nous faudrait un schéma détaillé de votre modèle physique de production. Avez-vous fait un MCD de votre projet?
Et le minimum syndical un show create table de chaque table de votre BD.

Quel SGBDR utilisez-vous et en quelle version? Avez-vous fait au préalable une étude à savoir si le SGBDR choisi est capable de répondre au cahier des charges de votre applicatif au moins en terme de charge?
Quel est le type et la configuration de votre hébergement?

Qu'est ce que vous tuez dans votre serveur? Pour y répondre avez-vous consulté les logs apache? et ceux de votre SGBDR? (incluant le slow log queries)

Ensuite dans une requête lorsque l'on fait un FROM A LEFT JOIN B, on ecrit pas ensuite ON B.id=A.id mais ON A.id=B.id
Donc on doit ecrire :
FROM A LEFT JOIN B ON A.id=B.id
FROM A RIGHT JOIN B ON B.id=A.id

Pourquoi est-ce important? Car si vous inversez l'ordre, vous risquez de vous retrouver comme il vous arrive actuellement quand vous avez plusieurs lignes en réponse à votre jointure, de vous retrouver avec tous les ustensiles listés pour chaque étape de la recette. Ce qui peut être voulu dans une certaine mesure, mais je ne pense pas dans le cas présent.

Un petit rappel, lorsque l'on fait un WHERE sur une colonne de la table de droite dans une jointure à gauche cela revient à faire un INNER JOIN entre les deux tables.

Bonne continuation

Jc.

Dernière modification par Jc (29-12-2013 19:32:35)

Bonjour,

Merci également pour votre réponse j'apprécie également. Vous savez je ne suis pas du genre à vouloir décourager des personnes comme vous qui ont votre initiative et qui sont déjà capables d'aller où vous êtes allé, ça serait plutôt même le contraire. Donc très sincèrement continuez si cela vous botte et c'est un bon exercice pour les méninges donc cela ne peut vous faire de mal.
Ce qu'il faut comprendre à travers ma réponse c'est que si vous êtes la première personne intéressée par ma réponse, vous n'êtes pas le seul et c'est aussi pour les autres que je me suis permis aussi de répondre ainsi. Faire comprendre que cela ne s'improvise pas, que c'est un métier à part entière voir même plusieurs métiers réunis pour pouvoir répondre à toutes mes questions d'une manière professionnelle. Je tenais à ce que nos lecteurs, à travers votre problématique concrète, en prenne la mesure, tout simplement.

Ensuite, et toujours en toute amitié, si votre site se développe encore (ce que je vous souhaite), souhaitez-vous le gérer en tant que manager ou en tant que développeur? Ce que je veux dire par là, c'est qu'il va arriver à un moment où il vous sera très difficile de concilier les deux où alors au risque du devenir de l'activité même de votre site. Pensez-y, car j'ai fait dernièrement pas mal de validation de modèles économiques sur internet, et c'est malheureusement un problème récurrent pour développer les projets. C'est un peu comme quelqu'un qui fait 2 métiers en parallèle à 70h par semaine. Ca va un temps, mais arrive un moment où pour en faire bien un il faut faire un choix, sinon la machine ne suis plus, ou éventuellement on peut perdre les deux.

Bien que mon site ne soit plus du tout à jour (j'ai plus d'un an de retard dans sa mise à jour), sachez que je fais beaucoup de maîtrise d'ouvrage actuellement tant au niveau logicielle que base de données et je diminue progressivement ma part d'activité concernant la maîtrise d'œuvre, n'ayant plus 20 ans non plus. Donc s'il est vrai que je suis bien placé pour vous conseiller au mieux dans votre demande, faire les choses bien à ce niveau serait de vous apprendre le métier, mais je ne pense pas que cela soit ce que vous recherchez d'une part, ni ma vocation d'autre part bien qu'ayant eu par le passé un agrément éducation nationale en formation. Le sujet est très vaste vous savez, et je ne pense pas que vous trouverez des ouvrages de "synthèse" qui vous diront "pour tel cas de figure, le mieux c'est de faire cela", etc.. Surtout en base de données, l'administration c'est de l'artisanat, et la synthèse c'est l'artisan qui la fait, fort de ses connaissances et de son expérience.

Pour ce qui est des bases de données, je vous donnerai une très bonne référence à travers le blog de SQLpro qui vous donnera une idée de ce que l'on peut trouver sous le capot d'un SGBDR, et étant tout comme lui partisan des développement en SGBDR épais, vous comprendrez mieux aussi pourquoi en le lisant.
Pour ce qui concerne l'architecture logicielle, allez voir sur le forum développez.net rubrique ALM, vous aurez de la lecture également, et vous pourrez y poser des questions, peut être qu'à l'occasion je vous y répondrais aussi.

Pour ce qui est des requêtes je ne parlais pas forcément de requêtes SQL mais de requêtes HTTP sur votre serveur Apache. Vous avez de la marge quand on pense qu'avec certains sites construits avec des CMS que je ne citerai pas et atteints de "modulite aigüe", comme il me plaît à le dire, on peut atteindre parfois plus de 350 requêtes serveur pour afficher la page d'accueil, ce qui est insensé.
Si vous voulez connaître le nombre réel de requêtes serveur de votre site, ouvrez IE, faites F12, cliquez sur l'onglet "réseau", cliquez ensuite sur "démarrez capture" et faites un F5 sur la page d'accueil de votre site. Vous aurez une ligne par requête. Il vous suffira de les compter.

Pour ce qui est des égalités je vous rappellerai juste qu'il ne s'agit pas d'égalité au sens arithmétique du terme mais au sens relationnel. L'égalité représentant la jointure, il est donc normal qu'en faisant une jointure à gauche ou à droite, ce que vous placez à gauche ou à droite ait de l'importance, bien que parfois selon le contexte, cela ne peut avoir d'incidence (cas général des jointures INNER JOIN ou CROSS JOIN inclus).

Concernant le choix du serveur je travaille personnellement qu'avec des serveur VPS chez OVH pour mes solutions logicielles pour de très nombreuses raisons, libre à vous de choisir le vôtre.

En ce qui concerne "moins il y a de requêtes, mieux c'est", sauf cas particuliers, vous avez tout à fait raison.
La solution serait de passer par un GROUP_CONCAT pour agréger les résultats de vos requêtes dérivées avec un séparateur de chaîne bien choisi et réservé au sein de votre application, et de les récupérer en php via un explode().

Cordialement,

Jc.

Dernière modification par Jc (27-06-2013 17:18:59)