optimisation requete sql

[achaternet]

'soir,

Mon objectif est de remplacer plusieurs requetes imbriquées , donc trop lourde en 1 seul

<?

$partb="SELECT nom FROM chps_select";
$result = mysql_query ($partb,$db);

while($namme=mysql_fetch_object($result))
{
$nmtb=$namme->nom;

$query_titres="SELECT nom,url FROM `".$nmtb."` GROUP BY nom";
$result_titres = mysql_query ($query_titres,$db);

while ($lign=@mysql_fetch_object($result_titres))
{
$chainus=$lign->nom;
$kurl=$lign->url;
...
}
}

?>

L objectif etant de parcourir le contenu de toutes les tables indiqué par le parcours de la table chps_slect.

Comment coder la requete :roll: ?

Merci

 

[XenonDelee]

la syntaxe INNER JOIN ??? :roll:

SELECT table1.*,table2.* FROM table1 INNER JOIN table2 ON champs_table1=champs_table2  ....

Bon courage,

A+

 

[Oncle Tom]

Xenon dit vrai (enfin dis nous si ça marche) mais j'ai pas l'impression que la structure de tes tables soit au point. Faire 1 table par catégorie c'est pas bon du tout.

Pense aussi à utiliser le moins de variables possibles, c'est trop lourd pour rien :

<?
$result = mysql_query ("SELECT table1.*,table2.* FROM table1 INNER JOIN table2 ON champs_table1=champs_table2");

while ($lign=@mysql_fetch_array($result))
{
echo $lign['nom'];
echo $lign['url'];
// ça , en dessous, oublie ça sert à rien : tu doubles la mémoire utilisée pour des prunes.
// c'est comme si tu commandais 2 pizzas et qu'à la livraison, tu mettais au four 2 surgelées ...
//$chainus=$lign->nom;
//$kurl=$lign->url;
...

}

?>

 

[Bool]

Euh si le nom de la table est dynamique (cf ton "select xxx from $variable"), t'es franchement mal barré pour tenter d'optimiser quoi que ce soit...

 

[achaternet]

Je vois un peu ou vous voulez en venir,
mais en reprenant par rapport au contexte, je bloque:

chps_select est table1 (qui est fixe)

$nmtb est table2 (qui est variable) resultant du contenu de la colonne nom de la table chps_select

En reprenant avec INNER JOIN :

SELECT chps_select.nom, $nmtb.nom,$nmtb.url FROM chps_select INNER JOIN $nmtb.* ON nom=nom

CREATE TABLE `chps_select` (
  `nom` varchar(35) NOT NULL default '',
...
 PRIMARY KEY  (`nom`)
) TYPE=MyISAM;




CREATE TABLE `$nmtb` (
  `id` smallint(5) unsigned NOT NULL auto_increment,
  `nom` varchar(230) default NULL,
...
PRIMARY KEY  (`id`),
  KEY `knom` (`nom`)
) TYPE=MyISAM;

Attention le champs nom n est pas le meme:
`nom` varchar(35) NOT NULL default '', pour chps_select
`nom` varchar(230) default NULL, pour $nmtb

Il faut que je recup le nom et l url par le biai de la table $nmtb resultant du champs nom de la table chps_select.


Kesako :?:

Es ce bien INNER JOIN a utiliser? quelle syntaxe?

Merci

 

[achaternet]

Faire 1 table par catégorie c'est pas bon du tout.
?>

Tu propose quoi comme structure?

 

[Bool]

Classiquement : une seule table pour toutes les catégories, avec un champ identifiant la catégorie concernée.

 

[iconso]

Je ne suis pas sur d'avoir bien compris ton problème mais je crois que c'est l'opérateur UNION dont tu as besoin, si toutes tes tables $nmtb ont bien la meme structure : http://www.nexen.net/docs/mysql/annotee/union.php

Cet opérateur te permettra de récupérer le résultat de toutes tes requetes en une seule table. Par contre ce n'est pas ce que l'on peut appeler de l'optimisation... Dans ton cas je crois effectivement que tu vas devoir sérieusement repenser ta structure de tables. ;-)

Fred

 

[achaternet]

Merci a vous tous.

Je vais travailler dans ce sens...

Je ne suis pas sur d'avoir bien compris ton problème mais je crois que c'est l'opérateur UNION dont tu as besoin, si toutes tes tables $nmtb ont bien la meme structure : http://www.nexen.net/docs/mysql/annotee/union.php

Cet opérateur te permettra de récupérer le résultat de toutes tes requetes en une seule table. Par contre ce n'est pas ce que l'on peut appeler de l'optimisation... Dans ton cas je crois effectivement que tu vas devoir sérieusement repenser ta structure de tables. ;-)

Fred

lol, c est effectivement ça, mais c pas top vi. Fred , tu devrais migrer tous tes sites en php plutot que asp

 

[iconso]

Fred , tu devrais migrer tous tes sites en php plutot que asp

Mouarf... pas de troll STP

Fred

 

[Bool]

bah... il y a bien les tables "MERGE" sinon... mais ce n'est pas vraiment ça qui résoudra le problème.

 

[achaternet]

Dit moi iconso, sur i-comparateur, tu as fait quelle struture de tes diverses tables concernant tes produits :?: :?:

 

[iconso]

Pour les produits, une seule table suffit. Il te faudra au minimum des colonnes comme produitID, siteID (clef externe vers une table site contenant le nom du site, etc..), nom, prix. Ensuite tu peux ajouter diverses infos selon tes besoins dans ta table "produits" : les frais de port, la catégorie, etc... Une bonne structure de tables est vraiment indispensable pour un comparateur de prix : ca ne fait pas tout, mais c'est un point de départ indispensable.

Tiens d'ailleurs contrairement à ceux que certains peuvent penser : i-Comparateur n'utilise aucune technique de mise en cache, ou de pré-génération des pages HTM en dur : c'est du 100% live, à chaque page loadée.

Fred

 

[Bool]

Tiens d'ailleurs contrairement à ceux que certains peuvent penser : i-Comparateur n'utilise aucune technique de mise en cache, ou de pré-génération des pages HTM en dur : c'est du 100% live, à chaque page loadée.

Tiens donc... Petite curiosité alors : pourquoi ce choix ?

 

[iconso]

Tiens donc... Petite curiosité alors : pourquoi ce choix ?

Le cache peut être utilisé pour combler certaines lacunes de complexité d'exécution des requêtes. Par contre s'il est utilisé pour cela, la première personne qui interroge ta page une fois ton cache expiré va attendre pour les autres.... C'est un moindre mal c'est certain, mais bon.. ;-)

Ce qui caractérise souvent les comparateurs, c'est un grand nombre de pages, et donc uen importante dispertion des visites. Je ne connais pas le nombre de pages qui sont vues une seule fois dans la journée, mais il doit être assez important : l'intérêt du cache dans ce cas, c'est néant, pour ne pas dire pénalisant.

Dans tous les cas, il vaut mieux favoriser la vitesse naturelle d'un site, sans tenir compte de la capacité de mise en cache (qui pourra par contre représenter une possibilité pour augmenter la capacité d'accueil sur le meme matos) : c'est ce que j'ai essayé de faire.

Sinon le cache n'a pas que des avantages, surtout sur des sites comme les comparateurs, qui devraient pouvoir en théorie être remis à jour plusieurs fois par jour (ce qui en réalité est difficile, beaucoup de marchands imposant de "taper" dans leurs bases que dans les heures creuses). Le live te permet d'apporter des modifications dans les prix sans avoir à te soucier du moment ou elles seront répercutées sur le site.

Fred

 

[Bool]

mmm je ne te comprends pas vraiment. Les quelques systèmes de cache que tu as eu sous le coude devaient vraiment être mal faits. Un système de cache n'impose aucune contrainte de mise à jour : pour preuve, mon forum bénéficie de ce genre de système, tout comme 90% des pages de mon site.

Si je prend mon cas, à partir de 100ms, je sens un temps de latence. Et les caches me permettent justement de supprimer cela (15ms en moyenne par page). J'ai quelques 40'000 pages sur mon site, et ça ne pose aucun problème (j'utilise principalement des caches de données, et non des caches html). Le premier visiteur arrivant avant le tout premier cache aura peut etre un temps de génération de 200ms, mais toutes les pages suivantes se généreront plus rapidement car les caches sont réutilisés de page en page.

Dans le cas d'un comparateur, je trouve les caches encore plus adapté : un "vrai" cache se met automatiquement à jour lorsqu'on fait une modification sur une page. Et donc, pour la plupart des pages, même en supposant que tu fasses une mise à jour par heure, cela accélèrerait grandement les choses.

Enfin bon, je trouve ta démarche curieuse, mais libre à toi de gèrer ton site comme tu le sens

 

[achaternet]

Pour les produits, une seule table suffit. Il te faudra au minimum des colonnes comme produitID, siteID (clef externe vers une table site contenant le nom du site, etc..), nom, prix.
Fred

Ok. Si j'ai bien compris , en fait ensuite, lors d une recherche pour l affichage d un ou plusieurs produits, tu faits une requete croisé avec ta clef externe qui relie tes 2 tables, c est bien cela?

 

[achaternet]

mmm je ne te comprends pas vraiment. Les quelques systèmes de cache que tu as eu sous le coude devaient vraiment être mal faits...

Les meilleurs systemes de cache sont pour des sites en hebergement dedié (c est mon avis).

Moin vu que je suis en mutualisé, je n utilise pas de cache, mais compression de pages, avec la fonction ob_start("ob_gzhandler"); , mais ça c est en php

 

[Bool]

Justement mon système de cache m'a permis de rester le plus longtemps possible sur des hebergements mutualisés.

J'utilise également la compression de pages (via l'option dans le php.ini), ça ne pose aucun problème. Là dessus j'ai également un cache http, ça ne pose toujours aucun problème.

 

[achaternet]

Justement mon système de cache m'a permis de rester le plus longtemps possible sur des hebergements mutualisés.

T utilise quoi comme systeme de cache? (en mutu)

ton site est il dynamique?

 

[iconso]

Enfin bon, je trouve ta démarche curieuse, mais libre à toi de gèrer ton site comme tu le sens

Effectivement c'est un choix. Mais si tu m'as bien lu : je n'ai pas dit que je n'utiliserais jamais du cache. Simplement je n'en vois pas l'intérêt quant la plupart des pages sont générées en bien moins de temps que ce que tu annonces (donc la vitesse est la) et le temps CPU proche de 0 (donc il reste de la marge). Dans ces conditions je ne vois aucun intérêt intérêt à mettre en place un système supplémentaire.

Ignorer les problèmes et contraintes de mémoires et/ou d'accès disque lors de la mise en place d'un cache sur des volumes de données importants, c'est prendre des risques. Le cache n'est pas adapté à tous les sites, certains résultats peuvent même empirer après sa mise en place, en accentuant des points de blocages.

Ok. Si j'ai bien compris , en fait ensuite, lors d une recherche pour l affichage d un ou plusieurs produits, tu faits une requete croisé avec ta clef externe qui relie tes 2 tables, c est bien cela?

Oui, tu peux faire ce qu'on appelle des jointures. Voila une excellente ressource pour SQL en général : http://sqlpro.developpez.com/indexSQL.html Cela devrait déjà te donner quelques idées et de bonnes bases, même si MySQL ne supporte pas forcément toutes les fonctionnalités évoquées.

Fred

 

[Bool]

T utilise quoi comme systeme de cache? (en mutu)

euh... un système maison, basé sur cache fichiers et mémoires

ton site est il dynamique?

euh... ça existe encore les sites statiques ?

Effectivement c'est un choix. Mais si tu m'as bien lu : je n'ai pas dit que je n'utiliserais jamais du cache. Simplement je n'en vois pas l'intérêt quant la plupart des pages sont générées en bien moins de temps que ce que tu annonces (donc la vitesse est la) et le temps CPU proche de 0 (donc il reste de la marge). Dans ces conditions je ne vois aucun intérêt intérêt à mettre en place un système supplémentaire.

mmm, ce ne doit pas être une petite machine alors mais effectivement, tant qu'aucune lenteur n'est remarquable, pas la peine de s'embeter.

Ignorer les problèmes et contraintes de mémoires et/ou d'accès disque lors de la mise en place d'un cache sur des volumes de données importants, c'est prendre des risques. Le cache n'est pas adapté à tous les sites, certains résultats peuvent même empirer après sa mise en place, en accentuant des points de blocages.

Oui, entièrement d'accord, mais ce ne sont pas forcément des cas courants.

Si je prend le cas "extreme" d'un serveur hebergeant mysql très puissant avec un serveur apache "lent" (ou avec disque lent), il vaut mieux laisser tout le boulot à MySQL qui s'en sortira bien mieux qu'un petit cache fichier coté Apache.
Sur mon site, il peut arriver d'avoir en fin de journée quelques milliers de fichiers de cache générés, pour environ 200Mo de données ; l'intérêt n'est pas spécialement d'être plus rapide qu'une requête mais surtout de supprimer une contrainte majeure de MySQL : le nombre de connexions simultanées. Grâce à ça j'arrive à supprimer toute connexion à la base de données sur pas mal de pages, ce qui allège bien la charge, surtout sur un serveur mutualisé (sur un dédié, il suffit généralement d'augmenter le nombre de connexions).

Coté cache mémoire, la principale contrainte est bien évidement la quantité...
J'en reviens encore à mon cas : sachant que Turck MMcache compresse les données en mémoire, et que mon serveur a constament 250Mo de mémoire libre, j'ai de la marge... Je pourrais d'ailleurs désactiver la compression pour avoir un léger gain supplémentaire.