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 ?

Merci

[XenonDelee]

la syntaxe INNER JOIN ???

Code: Tout sélectionner

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 :

Code: Tout sélectionner

<?
$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

Code: Tout sélectionner


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