Discussion :

[El Riiico]

Bonjour,

je développe un moteur de recherche sur des annonces, où le code postal est tès important pour la recherche. La vitesse de ce moteur (qui est appelée à gérer une quantitée croissante d'annonces) est primordiale.
Les visteurs sont libres de saisir plusieurs codes postaux sous deux formats :
- En saisissant un code postal complet. exemple : 92100 (boulogne)
- Avec le numéro de département. exemple : 92 (élargit la recherche à l'ensemble du département)

Pour gérer dans ma requête SQL (Mysql 5), j'ai deux difficultés :
- Je dois interroger la table sur plusieurs valeurs (puisqu'on peut saisir différents codes postaux en même temps (un tri par prix ou localisation est ensuite possible))
- Ces codes postaux peuvent être de longueurs différentes (2 ou 5 caratères)

J'ai commencé à fonctionner ici avec la solution suivante :
Une recherche pour les départements avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE LEFT(table.codepostal,2) = "92"

Une recherche avec un IN() quand les formats sont identiques

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE LEFT(table.codepostal,2) = IN("92","75")

Des requêtes avec 'OR' quand il y a plusieurs codes de formats différents

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE LEFT(table.codepostal,2) = "75" OR table.codepostal = "92100"

Mais je n'aime pas cette solution avec 'OR' que j'ai toujours vue déconseillée dans les conseils sur SQL.

Après m'être renseigné, j'ai trouvé la solution de l'index de type FULLTEXT.
Qui permet de faire des recherches sur plusieurs mots comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE MATCH(table.codepostal) AGAINST('75* 92100') > 0.001

Un index de type FULLTEXT est-il pertinent sur un champs qui ne contient que 5 caractères ?

Il est pratique, mais est-ce qu'il est assez rapide pour un moteur de recherche qui est le coeur du site (un site d'annonces immobiliaires) ?
Je vous le demande avant de faire les tests, parce que ma table d'annonces est au format InnoDB, et que le FULLTEXT oblige à passer en MyIsam... ce qui ne m'arrange pas.

[KiLVaiDeN]

Bonjour,

Si ton souhait est d'optimiser la requête, il n'y aura rien de mieux que d'ajouter une champ correspondant au département et arrange toi pour le rendre numérique car c'est plus rapide à indexer ( comparaison numérique toujours plus rapide qu'une comparaison alphanumérique qui est en fait une série de comparaisons numériques ).

Ensuite, tu ajoutes un index sur ce champ. Et tu t'arranges pour faire uniquement des égalités dans ta requête, ainsi tu va grandement améliorer les temps de réponse.

Donc si la personne entre 92 75003 dans le champs, tu parses cette chaine, quand il y a 2 caractères et qu'il s'agit bien d'un numéro, tu passe l'égalité dans ta requête, et pareil pour quand il y en a 5.

Tu peux créer deux tables, une contenant les codes postaux, et l'autre les départements, et y faire référence ( avec une clé étrangère ) dans ta table des annonces. Je pense que c'est le moyen le plus efficace.

[El Riiico]

Je retiens ces conseils pour des recherches simples.

Mais ça ne m'aide pas pour mon problème qui est de sélectionner dans une requete par les annonces de départements différents.

Mise à part un lien avec 'OR', vous voyez une autre solution ?

[KiLVaiDeN]

Tu as aussi le choix d'utiliser UNION.

Mais le OR revient au même en temps de traitement dans ce cas, et vu qu'il est plus adapté semantiquement à la requête que tu souhaites formuler, il est plus adapté.

Il est difficile de toutes façons d'éviter d'utiliser des OR dans des requêtes multicritères, on peut optimiser un peu ( et j'en doute, mais je ne connais pas assez bien le mécanisme niterne des SGBD pour le savoir ) en faisant des sous-requêtes..

Je ne pense pas cependant que dans ton cas ça soit catastrophique, car étant donné que tu as optimisé la comparaison au point d'en faire une égalité, ça va être très rapide.

[Maximil ian]

Mise à part un lien avec 'OR', vous voyez une autre solution ?

A part IN(...), non. La recherche fulltext est, comme son nom l'indique, appropriée pour du texte relativement long et pas des valeurs numériques.

[El Riiico]

Je vous remercie, j'ai améliré ma requête pour que le 'OR' ne soit utilisé que lorsqu'on ne peut pas faire autrement, autrement la requête utilise IN() dans la mesure du possible.

[KiLVaiDeN]

Le IN soit dit en passant est un équivalent d'un OR pour une liste de valeur

Ca revient au même de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM table where (valeur = 1) OR (valeur = 2) OR (valeur = 3)

Que de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM table where valeur IN (1, 2, 3)

C'est juste une manière plus abrégée d'écrire la chose, je ne pense pas qu'il y ait une énorme amélioration du temps de réponse dans un cas par rapport à l'autre. ( Si quelqu'un pouvait confirmer, ça me rassurerait )

Une chose qui peut cependant être vrai, est que quand tu places tes tests dans un certain ordre avec des OR, tu peux ou non sortir de la condition plus rapidement.

Par exemple, si le premier test est vrai ( la valeur = 1 ) plus besoin de tester si elle est égale à 2 ou à 3.

Donc en plaçant les valeurs les plus probables en tête, tu risques d'améliorer encore un peu ta requête, et si ça se trouve le IN utilise des statistiques pour faire ce genre de classement en interne dans sa liste, mais je n'en sais rien.

A+