Discussion :

[dcz]

Bonjour,

Donc, je suis en train de mettre en place une application dont le but principal sera d'effectuer des recherches multicritères sur mysql (4.1).

La question que je me pose, vu le nombre relativement important de critères (plus de 15) est la suivante :

Vaut il mieux définir une table "element", avec une colonne par critère (element_id, inof1, info2, .., infoN, critere1, critere2 ... critereN) mise en index, ce qui implique pas mal d'index sur la table (un par critère), ou faire une table par critère (table critereN : element_id, critereN) et sortir les résultats avec un left join sur la table contenant les informations de l'élément, au risque d'avoir un nombre important de join?

J'ajoute que les recherches seront majoritairement multicritères, et pour une bonne partie avec la majorité des critères, il y aura relativement peu d'insert comparé aux select.

[ced]

Bonjour,

Personnellement, je penche pour le second schéma, et pour plusieurs raisons, notamment :

• trop d'index sur une même table peut dégrader les performances ;
• avec le second schéma, tu peux ajouter, voire enlever, des critères sans toucher à la structure des bases.

ced

[Antoun]

Si tu as des conditions de type "au moins 10 critères remplis sur les 15", la seconde solution s'impose.

[dcz]

Merci pour cette réponse.

C'est un peu ce que je me disais, j'ai juste un peu d'appréhension pour des left join sur 15 tables.

A propos des index, j'ai pas mal lu que ça ralentissait les insert, mais en lecture, et avec les colonnes sélectionnées dans l'ordre du plus grand nombre de doublons vers le plus petit, cela compte-il autant ?

Et du coup question subsidiaire, penses tu qu'une sorte d'entre deux puisse valoir la peine, genre regrouper les critères par catégorie de critère, et en faire une table. Ce qui donnerait des left join sur moins de tables, mais qui impliquerait des index dans les tables groupant des critères (en tout autant que sur la table qui les regrouperait tous).

L'évolution des critères n'est pas le plus important, c'est une opération qui serait dans mon cas exceptionnelle. Je cherche avant tout à optimiser les select.

Merci encore

[edit] @Antoun on poste en même temps lol.

Donc, pour préciser, l'application ne fera pas de select type au moins 10 crières sur 15, mais plus du type critere1 = xx and critere2 > yy and critere3 between zz and zzz etc ...

[Antoun]

Merci pour cette réponse.

C'est un peu ce que je me disais, j'ai juste un peu d'appréhension pour des left join sur 15 tables.

des LEFT JOIN sur 15 tables ???

[dcz]

Désolé, je dois pas être très clair.

Donc, si j'ai une table article avec des colonne purement informative qui définissent l'article de manière générale id, catégorie titre etc.
Je veux pouvoir trier ces information selon une 15 aine de critères pouvant tous être utilisés en même temps pour construire une liste d'articles satisfaisant ces critère. Par "critère" j'entends une colonne dont le contenu va très souvent être utilisé pour trier les résultats.

Genre tous les article de couleur bleu et dont le prix est inférieur à tant et la date de fin de promo et le etc ... sur une quinzaine de critères principalement des nombres qui varient en nombre de doublons de presque tous à presque aucun.

Je refait pas kelkoo, mais l'exemple est parlant. Un article dans plusieurs catégories à la fois en quelques sorte, le bleu, les vert ... .

Donc, comme cette table va vraiment être la plus sollicitée de l'appli, et très majoritairement en lecture, je suis intéressé par vos avis et expériences.

Je vois trois alternatives, soit tout mettre dans la même table avec des index, soit créer une table par critère, ce vers quoi ced à l'air de pencher, soit créer un nombre plus limité de table, qui grouperaient les critères, genre une table : aspect => colonnes : - id - couleur - matière - style
etc ..
Pour limiter le nombre de table en jointure.

Donc oui, j'ai toujours un peu d'appréhension pour des left join sur 15 tables, mais je vois pas comment éviter ça si je fais une table par critère. La troisième possibilité pourrait limiter le nombre de tables sélectionnées, mais j'ai l'impression qu'on y gagnerait pas tellement en index, donc ...

Bon je me prend peut être un peu la tête, mais comme c'est le moment

[Antoun]

Une requête qui utilise les quinze critères sollicitera les quinze index (s'ils existent et si l'optimiseur les juge rentables), qu'ils soient dans une seule table ou dans quinze. Elle sera donc plus rapide si tout est dans la même table, parce que tes 15 jointures externes vont être très pénalisantes.

plus généralement, le partitionnement vertical (déplacer des colonnes dans une autre table) n'améliorera que les requêtes qui n'utilisent pas ces colonnes. Les autres requêtes seront au contraire ralenties par la jointure. Autrement dit, le partitionnement vertical n'est intéressant que pour isoler des colonnes rarement utilisées.