Script efficace pour moteur de recherche d'articles

Version imprimable

Bonjour à tous,

Voici le script pour générer le filtre de ma requête de mon moteur de recherche pour trouver des articles du shop
Dans lequel vTabFiltre contient les mots de la recherche.
Par exemple pour une recherche "Ordinateur usb-2 TTRDF/2GB" le vTabFiltre contient :
Ordinateur
usb
2
TTRDF
2GB

Je découpe la chaine sur tout les caractères spéciaux.
Code:

1 2 3 4 5 6 7 8 9 10 11 For vCpt = 0 To UBound(vTabFiltre) If Trim(vTabFiltre(vCpt)) <> "" Then If vFiltre <> "" Then vFiltre &= " AND " vFiltre &= " (CODE LIKE '%" & vTabFiltre(vCpt) & "%'" & _ " OR DESCR LIKE '%" & vTabFiltre(vCpt) & "%' COLLATE French_CI_AI" & _ " OR GROUPE LIKE '%" & vTabFiltre(vCpt) & "%' COLLATE French_CI_AI" & _ " OR ONGLET LIKE '%" & vTabFiltre(vCpt) & "%' COLLATE French_CI_AI" & _ " OR MARQUE LIKE '%" & vTabFiltre(vCpt) & "%' COLLATE French_CI_AI)" End If Next
Il faut recherche à la fois dans le code, la description, le groupe, le sous-groupe et la marque.

Ce code est il adapté à votre avis ? Car le souci c'est que quand le nombre de mots de la recherche augment le temps d’exécution de la requête augment considérablement.

Y a-t-il mieux selon vous ?

Merci d'avance

15/02/2012, 14h05
calagan99

Bonjour,

une première remarque pour commencer : utilise les requêtes paramétrées pour gagner en lisibilité et sécuriser ton application.

Sur le fond, ce n'est pas tant le code qui compte que la modélisation de ta base et le paramétrage de tes tables et colonnes.
Si tu as une grosse quantité de données et de nombreux accès ton application, il est fort probable que ta méthode soit rapidement inadaptée. Si ce n'est pas le cas, la solution n'est peut-être pas optimale mais fonctionnera.
Si tu es dans le premier cas, il faut peut-être que tu t'orientes vers des recherches full-text mais il faudra alors reprendre une partie de ta modélisation.
15/02/2012, 15h07
StringBuilder

Citation:

Envoyé par calagan99

une première remarque pour commencer : utilise les requêtes paramétrées pour gagner en lisibilité et sécuriser ton application.

et en performances

Citation:

Envoyé par calagan99

Sur le fond, ce n'est pas tant le code qui compte que la modélisation de ta base et le paramétrage de tes tables et colonnes.
Si tu as une grosse quantité de données et de nombreux accès ton application, il est fort probable que ta méthode soit rapidement inadaptée. Si ce n'est pas le cas, la solution n'est peut-être pas optimale mais fonctionnera.
Si tu es dans le premier cas, il faut peut-être que tu t'orientes vers des recherches full-text mais il faudra alors reprendre une partie de ta modélisation.

Je ne pourrai apporter en complément qu'une unique chose : la désignation qui est donnée en exemple semble porteuse d'informations : 2GB est une quantité de mémoire, et donc devrait être un attribut. Idem pour USB-2 qui pourrait être orthographié de plusieurs façons différentes d'un produit à l'autre.
Par conséquent, la désignation de ton article doit comportement une description la plus "française" possible, pas de codes, et surtout, pas d'attributs !
En revanche, dans ton moteur de recherche, des cases pour rechercher les articles avec l'attribut usbtype = 2, ram = 2, etc.
Ceci permettra d'améliorer considérablement à la fois la vitesse de traitement, la maintenabilité de ton fichier de données, et la qualité des résultats.

En effet, si je fais une recherche "ordinateur usb 2"
=> Avec ton système actuel, vu que je vais chercher "ordinateur", "usb" et "2" séparément, je vais aussi retrouver "Cable usb pour IPad2 pour se connecter à un ordinateur"
Sauf que moi, je veux un ordinateur, pas un câble...
15/02/2012, 15h22
aloisio11

Citation:

Envoyé par StringBuilder

=> Avec ton système actuel, vu que je vais chercher "ordinateur", "usb" et "2" séparément, je vais aussi retrouver "Cable usb pour IPad2 pour se connecter à un ordinateur"
Sauf que moi, je veux un ordinateur, pas un câble...

Merci pour vos réponse.

Hélas je n'ai pas trop le choix du "formatage" de la BD et je dois donc me baser sur cette description.

J'essayais de trouver quelque chose de plus optimal.
15/02/2012, 16h31
nid4mail

Voici une solution que je mettrais en place : je chercherais tout ce qui contient "Ordinateur" ET "TTRDF" et dans les résultats je chercherais ensuite "USB2" (si je trouve je les place en premiers, sinon ensuite) (en retravaillant la chaine de caractères pour choper USB 2, USB-2, USB/2,...) puis pour avoir un classement par pertinence...
15/02/2012, 17h11
calagan99

Citation:

Envoyé par nid4mail

en retravaillant la chaine de caractères pour choper USB 2, USB-2, USB/2

Ca c'est de la recherche FullText :)
15/02/2012, 17h44
StringBuilder

Oui, c'est clair que la réponse à retenir de ce topic, c'est principalement qu'il faut utiliser Fulltext.
(Et les requêtes paramétrées).

Et LIKE, c'est un truc qu'il faut s'empresser d'oublier.
15/02/2012, 19h01
Nicolas Esprit

Tu peux aussi regarder Lucene.
16/02/2012, 11h15
Bluedeep

Bonjour

Pour donner un avis sur ton approche, il faudrait qu'on connaisse tes structures de tes tables ==> poste le DDL des tables en question.

Ensuite, je pense que tu ne pars pas dans le bon sens : on écrit ce genre de truc sous la forme d'une ou plusieeurs procédures stockées, qui recevront les différents paramètres de recherche, et qui pourra aussi inclure des choses comme des recherches textuelles "approximatives" (algorithme des distances de Levenstein ou équivalent) ; en tout cas, cela n'a pas à relever du code applicatif mais clairement du code porté par le SGBD. (SQL ou éventuellement langage classique pour certaines fonctions suivant le type de SGBD considéré : C#/SQLCLR pour SqlServer, Java pour Oracle, etc ....).