J'au une table que me sert à gérér une arborescence et qui se présente comem ça :
 
| Id | Lvl | Nom_fr | Nom_us | Pere |
 
jusque là rien de très sorcier le champ Pere se rapporte à l'identifiant pour retrouver la relation Parent / Enfant.
 
Dans une autre table, je stocke des articles avec des champs Cat1 et Cat2 qui se rapportent à la catégorie dont ils font partie.
 
Le hic : quand je veux lister tous les articles d'une sous-catégorie et de toutes ses catégories-filles je me retrouve avec 10 ligne de Cat1=X OR Cat2=X etc.. pour chaque catégorie fille. (en fait je parcourt un tableau codé en dur à chque modif de la table pour récupérer les différentes sous-cats, donc une seule requête sur la base)
 
Question 1 : Incidence grave sur les perfs ? (pour l'instant ça n'a pas l'air lent..)
Question 2 : Si réponse positive à la question 1 comment faire plus propre ou plus rapide ?
 
Voici la requête SQL complète au cas où :

bon bin y a plus qu'a attendre joce

Et si tu mettais en place une table de paramètre dans laquelle serait stockés les codes de catégorie valides ?
 
Deux avantages :  
1. ta requête serait beaucoup plus simple : tu n'aurais qu'à faire une jointure entre Articles.Cat1/Articles.Cat2 et ton champ avec les codes de la table de param.
 
2. tu n'aurais qu'à changer le contenu de la table de paramètre en cas de MAJ de ta liste de code (la jointure définie précédemment restant valable).

+1
et la jointure sera sans doute plus rapide que ton OR OR OR OR

sinon tu peux aussi faire WHERE cat1 IN (45, 64, 53) OR cat2 IN (3, 18, 25) ça sera qd meme plus court et lisible

irulan > je pige pas ce que tu voudrais faire en fait qu'est ce que tu entendas par les code valides ?
 
greg > m'en vas tester le IN

OK greg effectivement je n'y ai pas pensé du tout c'est bien mieux comme ça (déjà la requête est moins longue donc certainement plus rapide à analyser)
 
J'attends les précisions d'irulan pour tester son système.
 
Merchi !

Bon en fait ta liste de codes qui sont dans les OR (ce que j'appelle les codes 'valides' tu les mets dans une table dans ta base de données, genre :
 
 
CODES_VALIDES
-------------
1
3
4
5
59
6
60
...
 
Maintenant imaginons que ta table s'appelle TABLE_PARAM, avec la colonne CODES_VALIDES, ta requête serait alors :
 
SELECT DISTINCT  
Articles.Id,  
Articles.Prix,  
Articles.Cat1,  
Articles.Code_interne,  
Articles.Dispo,  
Articles.Promo,  
Articles.Tva,  
DATE_FORMAT(Articles.Date,'%Y-%m-%d' as Date, Desc_articles.Nom_fr,  
Desc_articles.Desc_fr,  
Fournisseur.Nom as Marque  
FROM Articles, TABLE_PARAM  
LEFT JOIN Desc_articles ON Articles.Id = Desc_articles.Idx  
LEFT JOIN Fournisseur ON Fournisseur.Id = Articles.Fournisseur  
LEFT JOIN Categories ON Categories.Pere = 1  
WHERE (Articles.Cat1 = TABLE_PARAM.CODES_VALIDES or
 Articles.Cat2 = TABLE_PARAM.CODES_VALIDES)

J'ai oublié : si les codes valides ne sont pas les mêmes pour cat1 et cat2 il suffit d'avoir deux colonnes de valeur dans ta TABLE_PARAM, chacune correspondant aux valeurs désirées pour cat1 et cat2.

Et un dernier truc : si les jointures ne marche pas correctement (je n'ai pas bien regardé ta requête, notamment avec les left join) tu peux utiliser ... cat1 IN (select codes_valides from table_param) OR cat2 IN (select codes_valides from table_param)  
 
Cette solution se rapproche de la syntaxe proposée par greg, tout en gardant la facilité de maintenance liée à l'utilisation d'une table pour stocker les valeurs.
 
Mais bon je n'aime pas trop utiliser les IN c'est plus gourmand que des jointures....

c'est pas plutot le select imbriqué qui est gourmant? (et non le IN  en lui meme) (juste une question)

ok...
 
j'ai peu être oublié de préciser : les codes valides sont déjà récupérés d'un table mais ensuite insérés dans un tableau multidimensionnel pour éviter les requêtes multiples en coursde navigation (le tableau est mis à jours lors de la modification de la table).
 
le problème c'est que j'ai TOUT les codes, pas seulement ceux qui m'intéressent
 
quand j'arrive sur la page où jai besoin de cette requête, je parcours le tableau pour en récupérer les catégories filles et je génère la requête
 
donc ta proposition ne convient pas pour mon truc, c'est une jointure classique mais que je ne peux pas appliquer car je ne connais pas à l'avance les éléments pour l'effectuer.
 
merci quand même

greg > Non j'ai la notion que dans le cas d'un IN (ou alors c'était pour un NOT IN ? me souvient plus exactement ) le SGBD va examiner les lignes une à une contrairement aux jointures : je sais que du temps ou je travaillais sur des tables de 14 millions d'enregistrements, tu faisais vite la différence entre un IN et une jointure.
 
Bon maintenant j'ai peut-être une fausse idée du IN / NOT IN

pour info
 
fait select table1.champ,table2.champ FROM table1,table2 c'est exactement pareil que le LEFT JOIN (cf la doc)

Sh@rdar a écrit a écrit : ok... ... quand j'arrive sur la page où jai besoin de cette requête, je parcours le tableau pour en récupérer les catégories filles et je génère la requête ... merci quand même

 
Ben à toi de voir, mais si tu as vraiment des problèmes de perf, gardes cette solution à l'esprit : en effet, rien ne t'empêche de créer (puis dropper une fois la requête effectuée) une table temporaire où tu insères les valeurs à chaque fois.
 
Ce n'est pas long la création d'une table, en revanche ça peut tout changer au niveau d'une requête dans ce genre-là.

Retourne 1 si expression est un membre de la liste IN, sinon retourne 0.Si toutes les valeurs de la liste IN sont constantes, alors elles sont toutes converties au type de expression, et triées. La recherche dans la listes est alors faite avec une recherche binaire. Cela signifie que la recherche est très rapide si la liste IN ne contient que des constantes. Si expression est une chaîne sensible à la casse, la comparaison avec les valeurs de IN en tiendra compte.  
 
apparemment ça doit être assez rapide sur des entiers comme pour mon cas (de toute façon j'aurais pas 20 millions de catégories d'articles dans une boutique..)

 
Ok merci pour l'info sur le IN . Je me coucherai un peu moins bête ce soir

Si je me trompe pas, un "select table1.champ,table2.champ FROM table1,table2" ne permet de sortir que les lignes qui ont une cosrespondance dans les deux tables.
un LEFT JOIN, permet de sortir toutes les lignes de la tables situé à gauche des motes LEFT JOIN et les valeurs corespondant à l'autre table quand elles existent sinon des valeurs mises à null.
Mais bon, comme je les utilisent jamais, je peux me tromper.

 
ca c une jointure externe a gauche left OUTER join

Désolé, j'ai rien dit alors.

Les OR sont à éviter le plus possible, ils ne sont pas optimisés par l'optimizer de MySQL (donc perfs faibles).
A la limite si tu as MySQL 4.x utilise UNION à la place.

dit joce, mysql, ça leur arracherait la gueule de releaser une version4 un jour

--greg-- a écrit a écrit : dit joce, mysql, ça leur arracherait la gueule de releaser une version4 un jour

ba tu vas sur mysql.com et tu cliques sur 4.0.3 à droite

joce a écrit a écrit : ba tu vas sur mysql.com et tu cliques sur 4.0.3 à droite

ben ptain j'en viens et j'ai vu que des beta

--greg-- a écrit a écrit : ben ptain j'en viens et j'ai vu que des beta

ah ba vi, mais bon faut tester avant de releaser en finale hein
Ceci dit à mon avis la 4.0.4 sera probablement déclarée comme stable

joce a écrit a écrit : ah ba vi, mais bon faut tester avant de releaser en finale hein Ceci dit à mon avis la 4.0.4 sera probablement déclarée comme stable

ben je sais. mais ça fait quand meme longtemps là nan?
une idée de pour quand c'est la 404? (si on arrive à la downloader )

--greg-- a écrit a écrit : ben je sais. mais ça fait quand meme longtemps là nan? une idée de pour quand c'est la 404? (si on arrive à la downloader )

bientôt je pense, ca fait longtemps que j'ai pas vu de bug report contre la 4.0.4

ça fait lgtps qu'ils disent bientot non?

--greg-- a écrit a écrit : ça fait lgtps qu'ils disent bientot non?

non, leur politique c'est de la sortir en Stable quand il y a plus de bug report pendant un temps T.
Après si tu trouves ca nul, ba prends la beta au lieu de raler.

non, non, c'est tres bien. C'est juste qu'il me semble que ça fait une éternité qu'elle est en beta. spa grave.
Merci des infos  

--greg-- a écrit a écrit : non, non, c'est tres bien. C'est juste qu'il me semble que ça fait une éternité qu'elle est en beta. spa grave. Merci des infos

non elle est en beta depuis la 4.0.3, avant elle était en alpha
Donc c'est assez recent

joce a écrit a écrit : non elle est en beta depuis la 4.0.3, avant elle était en alpha Donc c'est assez recent

ok

pour info le forum HFR tourne depuis ce matin avec MySQL-4.1

ah d'accord, les plantages précédents étaient donc dus à la migration      
 
patapai !!! jsuis déjà dehors.

Sh@rdar a écrit a écrit : ah d'accord, les plantages précédents étaient donc dus à la migration         patapai !!! jsuis déjà dehors.

non y a pas eu de problème à la migration