Bon je sais que le code est long mais sait-on jamais....
Voilà, quand je demande un mot ($REQ) , tout se passe bien, la routine tourne nickel.
Dès que j'en demande plusieurs...... ça me met cette erreur bizarre. J'ai cherché sur Google mais ça me sort des résultats pour super matheux....
 

Toi, tu veux flinguer ton SGBD
Déjà, pour éviter certains OR, tu peux faire :
SELECT ... FROM ... WHERE CONCAT(TITLE, TEXT) ~*$1 OR CONCAT(TITLE, TEXT)  ~* $2 ...  OR CONCAT(TITLE, TEXT)  ~* $21
 
Dans ta table, ça vaudrait même le coup d'avoir un champ qui soit déjà la concaténation de TITLE et TEXT pour accélérer la recherche. Mais les 21 OR sont mettre à genoux ton SGBD si ta table est grosse. Regardes s'il n'y a pas l'équivalent de MATCH... AGAINST de Mysql.
 
Sinon, pourquoi 21 mots recherchés d'un coup ? Ca vient de quel besoin fonctionnel ?

Ha ha ha ha merci !!!
Je tatonne au niveau des expr reg avec Postgre et j'avoue que j'ai un peu de mal.
En fait si l'expression est dans le titre je lui donne un certain poids, et un poids différent si elle est dans le texte. et si il y a encore d'autres expressions je rajoute un autre facteur au poids.... Donc voilà, l'endroit où je chope l'expression a son importance.

Tu veux faire quoi exactement au niveau fonctionnel ? Parce que vu la tronche de ta requête, ça sent la BD mal structurée

L'idée c'est de construire un petit moteur de recherche

Ok, alors c'est bien ce que je dis, la structure de ta BD n'est absolument pas adaptée.
Tien, pour t'inspirer : https://fr.wikipedia.org/wiki/Analy [...] ue_latente
J'ai déjà implémenté cet algo qui marche bien (en gros, c'est un calcul de corrélation entre 2 vecteurs, chaque vecteur représentant un "document" et chaque dimension du vecteur étant un mot lemnisé). Pour la lemnisation, tu peux prendre la BD libre Lexique.org.

Ahhhh
Ca semble très interessant en effet.

Aucune idée de quel est ton niveau, mais pour quelque chose comme ce que tu décris j'aurais fait:
 
- un index qui est un tsvector d'une concaténation de title + texte pour que la recherche soit rapide.
 
Et ensuite la magie de rank:
https://www.postgresql.org/docs/9.1 [...] trols.html
 
Mais bon c'est peut etre un peu hardcore

Pour le moment ce que je fais c'est ça:
Je crée une table correspondant au résultat de la requete et j'y envoie les resultats (url, description, titre) comme ça c'est plus léger.
j'integre plusieurs variables, entre autres une pondération calculée sur l'emplacement de la recherche.
Si on trouve la recherche dans le titre, le document a une plus grande importance, on multiplie le nombre d'occurences par 25
Si on trouve la recherche dans le corps de texte, on multiplie le nombre d'occurences par 15.
a+b=occ
on remplit donc une colonne du tableau et on trie en  fonction de cette colonne.
Après, la table en question est mise à jour sur commande.

Mais maintenant ce que je vais faire, je vais casser les chaines de requete en sous groupes de mots, je vais devoir repenser les requetes car ca va peser lourd.
exemple: requete = LE GROS CHIEN
résult "le gros chien" aura forcément un poids plus important que résult "regarde le chien comme il est gros" qui sera également plus lourd que "le chien est gros" etc etc

J'ai regardé, je pense que ta solution est une version simplifiée de l'algo LSA. Ca parle de vecteur et poids. Ca ressemble à ma solution sauf que la mienne est un peu mieux car on lemnise les mots et on affecte un poids avec le TF-idf. A la fin, on fait le produit matricielle de tX*X (où t est l'opérateur "transposée" et X la matrice qui contient en colonnes, les documents et en lignes, les mots avec leur nb d'occurrences corrigé par le TF-idf). Pour info, la dernière partie de l'algo qui consiste à faire une ACP (calcul des valeurs et vecteurs propres) n'est pas une obligation. Elle permet de diminuer la taille de la matrice en compressant l'info et en retirant le "bruit". Moi, je me suis arrêté au calcul de tX*X et ça le fait déjà bien. Ce produit permet de calculer le taux de corrélation entre les documents (donc leur proximité). A noter que le calcul de X*tX permet de calculer le taux de corrélation entre les mots. D'une certaine manière, un taux élevé peut indiquer une appartenance au même champ lexical voir indiquer un synonyme. Dans le cadre d'un moteur de recherche, ça permettrait d'étendre la recherche par mots-clés en ajoutant à cette requête des mots-clés proches de ceux saisis.

Fichtre...
Me lancer dans du calcul matriciel à 22h...
Je vais me jeter dessus demain matin.
Merci encore

Le calcul, tu peux le faire soit par un binaire écrit en C/C++ soit en SQL direct avec une table de la forme (NumLigne, NumCol, Valeur).

Ca tombe bien, c'est deja fait, ca s'appelle tsvector comme dit
 
https://www.compose.com/articles/in [...] ostgresql/
 
Et ca gere meme des trucs que tu as pas pensé et pourtant nécessaire, genre créer les lexèmes, histoire qu'une recherche de "chienne" donne le résultat qui contient chien aussi.
 

 
Oui, tout ca, ou alors tu fais un tsvector, qui te fait ca comme un grand tout seul, c'est deja la, c'est foutrement plus perf que du PHP, et ça permet même encore plus de choses en fait.
 
 
Grosso merdo, ca donnerait un truc comme ca:
 
La table:

 
L'index (ca doit commencer par créer une fonction qui concatène tout le machin):

 
J'ai mis plus ou moins comme tu as dit:  A B C definissent le "rank", donc ici un truc trouvé dans le titre ($1) aura plus d'importance qu'un truc dans l'url ($2) et en dernier la description.
 
Ensuite on créé l'index:

 
Pour avoir la liste de ce que tu peux mettre dans la colonne 4 de cette fonction:

 
Et si tu veux faire dans l'international il te suffit de rajouter la langue en texte dans la table et de changer l'index:

Bon là il est 23h....
Mais c'est super sympa !

Ca c'est pour la création du bouzin (c'est un peu chiant, mais ca vaut le coup), ensuite on insere 2/3 trucs:
1 https://google.com Une description de chien, les chiens c'est bien Un super chien
2 https://facebook.com Une description avec des animaux ici point de C...
 
On vérifie que le tsvector est bien créé:

 
On est bon
1 'bien':13C 'chien':3A,8C,10C 'descript':6C 'google.com':4B 'le':9C 'sup':2A
2 'animal':8C 'descript':5C 'facebook.com':3B 'ici':1A 'point':2A
 
=> oui un tsvector ca ressemble a ca (c'est comme ca qu'il l'enregistre):
'bien':13C => il a trouvé bien en 13eme position, son ranking est 'C'
'sup':2A => il a trouvé sup en 2eme position (super a l'origine), son ranking est 'A'
 
Bref ca se stocke comme ca

Et ensuite tu peux query:

 
2 ici point de C... Une description avec des animaux
 
 
Ou encore:

 
1 Un super chien Une description de chien, les chiens c'est bien

Tu remarqueras dans l'exemple du dessus que facebook.com vient de l'url, mais chien vien de la description, la magie
 
Allons plus loin:
3 https//instagram.com Ici point de C. Mais chiennes est dedans Ca marche aussi
 
Il n'y a pas chien, mais chienne, s'parti:

 
Résultat:
1 Un super chien Une description de chien, les chiens c'est bien
3 Ca marche aussi Ici point de C. Mais chiennes est dedans
 
On est bon.
 
 
Le tsvector c'est le bien pour ca.
 
 
Deux choses: Note que je re-écrit exactement le tsvector tel qu'il est dans la fonction, sinon tu profites pas de l'index et tout s'écroule en terme de perf.
 
Donc faut bien penser a creer correctement ton index (tu peux aussi choisir de faire un champ en BDD et d'ajouter un trigger pour recalculer le champ a chaque création/update de la ligne, mais l'index tout est en ram et s'plus perf).
 
De deux, la syntaxe n'est pas du SQL classique, c'est une autre syntaxe:
https://www.postgresql.org/docs/10/ [...] earch.html
 
Et quand tu veux query to doit passer par un tsquery (donc pas une chaine de caractere classique), mais ca marche bien.
 
Ca supporte bien d'autre chose (comme par exemple: trouve moi un article avec chien suivit de chienne, dans cet ordre, pas plus de 3 mots entre les deux => ce genre de truc ca peut se faire en tsquery).
 
 
C'est par contre pas indiqué si tu cherches des mots incomplets.
Par exemple ca ratera a trouver "incomp" car c'est pas un mot complet. Ca ne marche bien que pour des mots complets.
 
Mais c'est dans tous les cas ce qu'utilise la plupart des gens aujourd'hui quand ils font du ranking sur du full text search...
 
EDIT: on est d'accord que si tu veux mettre url et titre en A et description en D comme ranking c'est bien sur parfaitement possible, a toi de tweak comme tu veux le truc...

Devil'sTiger, j'ai du mal à croire que Postgres intègre un algo de lemnisation pour le français. Ton exemple de chien/chienne est simple car chien est une sous-chaîne de chienne (on enlève "ne" de la fin). Mais je doute que ça marche avec un verbe conjuguer, genre irais/allé
Mon algo sait, grâce à l'étape de lemnisation (via la BD Lexique.org), que irais et aller sont le même verbe : aller (oui, la BD contient aussi l'info sur la forme grammaticale de chaque mot : nom commun, adjectif, verbe...). Y'a même des stats sur la fréquence d'occurrence de chaque mot dans les livres et dans les vidéos (si je me souviens bien).

Oh tu sais Postgres est probablement une des meilleurs BDD disponible aujourd'hui, tu peux en faire a peu pres ce que tu veux, si tu veux integrer des mots nouveaux, ou que tu n'es pas satisfait de sa lexemisation actuelle:
https://www.postgresql.org/docs/10/ [...] -THESAURUS
 
Une autre facon:
https://blog-postgresql.verite.pro/ [...] earch.html
 
Bref je pense vraiment pas que réinventer la roue soit un truc a faire sur une question comme celle-ci... C'est infiniment trop compliqué, et si c'est juste une histoire de dico et de lexème Postgres t'autorise a creer tes dico perso .

D'ailleurs:
4 Je suis Vous prendriez bien un peu de thé
 

 
Ca match.
 
Par contre "je suis" ne match pas, mais c'est parce que suis est dans ce qu'on appelle les stop words. Mais pareil ca peut se changer

Ok, je vois le genre. Après, je fais partie de ces gens qui considère qu'un SGBD devrait faire uniquement du stockage et extraction d'infos et non de l'applicatif. Implémenter une logique métier dans une BD, de mon point de vue, ça ne devrait pas se faire.

Je vois pas bien le problème... Ce sont des systèmes (tous les full text search de la planete, elasticsearch & co) taillées pour approcher la recherche d'un utilisateur au mieux avec ce qu'il y a dans la BDD, en partant du principe que le matching est jamais ultra parfait (chien vs chiennes par ex.). Ca me parait pas mal rester dans les cordes de ce que l'on attend d'une BDD, sortir la bonne info quand on lui fait une requête me parait pas etre de l'applicatif mais du B.A.BA d'un SGBD.
 
La question c'est est-ce que tu en as quelque chose a faire? La majorité du cas ce sera non, si tu fais un moteur de recherche pour ton site, tout ce qui t'intéresse c'est que la recherche marche au sens où l'utilisateur l'entend, cad avec les imperfections, et un ranking qui tient la route... C'est ce que font ces systèmes avec plus ou moins de succès.
 
tsvector est l'approche de postgres pour ca, et dans la catégorie il est loin d'etre minable, mais si il ne convient pas, l'étape du dessus c'est elasticsearch que l'on recommande le plus souvent...

C'est par rapport au découpage fonctionnel et architectural de l'appli que ça me pose souci qu'un SGBD empiète sur la partie applicative. Je suis peut-être vieux jeu, mais j'aime bien pouvoir tracer des frontières bien nettes entre qui fait quoi. C'est notamment utile dans la recherche des bugs. Si un truc marche pas bien parce qu'en fait, c'est la fonction du SGBD qui est boguée, ça va compliquer les choses (oui, j'ai déjà eu le cas avec la fonction qui donnait le n° de semaine d'une date dans Mysql 3.23 --> jeu peux te dire que j'ai mis un moment à trouver que ça venait de là parce que je partais du principe que les fonctions de Mysql fonctionnaient).

 
Bonjour et merci du tuyau...
Je lis vos messages avec grand interêt  
Je viens de rajouter une colonne à ma table de départ, celle qui contient tout le foutoir au départ.  
Cette colonne contient les mots (une seule fois) contenus dans le texte.
Ca allège énormément en effet pour la recherche.
Donc concernant la recherche il faut que je revois la logique, je suis en train d'attaquer mot par mot alors que jusque là je recherchais une expression complète.
Finalement, plus besoin de chercher une expression complète, on la recherche mot par mot et si l'expression complète figure dans un résultat c'est encore mieux....
Donc beaucoup de pistes à creuser.
 
Merci encore

   (fier)
J'ai fait un gros truncate et je viens de relancer la bête.
petite requête d'actualité sur "Didier Raoult" sur actuellement 75.000 pages indexées.  
C'est pas mal, en fait on se rend compte que M. Didier apparait 17 fois dans le texte de la première page.
Donc j'ai gardé dans une colonne le texte complet mais je ne l'indexe plus.
J'ai donc créé une colonne que j'ai appelée REGEX (allez savoir pourquoi....) dans laquelle j'insère un exemplaire de chaque mot trouvé sauf tous les mots "à la con"
Au début j'ai eu des problèmes avec des éventuels résultats du genre "Raoult Didier" auquel je devais donc attribuer un poids moindre qu'à "Didier Raoult" qui est la requête originale mais j'ai bricolé avec les pondérations et j'ai trouvé !!
Merci encore... J'avance.

 
Oui ca peut etre frustrant, mais ton exemple est parlant: tu as un bug trouvé, sur une version qui a maintenant plus de 20 ans (enfin si je lis wikipedia ca date de 2000 Mysql 3.x), combien de bugs sur tes applications depuis?
 
Ces logiciels sont bien plus testés que la majorité des applications faites par les gens qui les utilisent... De plus, niveau fix de bugs, PostgreSQL autant que je sache est souvent cité comme un des codes vraiment stable et réactifs si un bug est trouvé (en tout cas de ce que je lis bien plus que MySQL, souvenons de l'épisode utf8, ca en dit long)...
 
Mais c'est surtout la question de la recherche dans du texte en elle même, c'est une question qui mobilise des équipes entières a travers le monde, qui évolue tout le temps, c'est pas vraiment un domaine ou prendre un dico va te donner un bon résultat, ou alors tu travailles sur un nombre vraiment très restreint de possibilité de recherche... D'ou le fait que je présente tsvector, même si je me doute que c'est peut être pas du niveau pour erwan83...

Pour qu'il n'y ait pas d'ambiguïté, j'ai laissé Mysql 3.23 pour un mysql bien plus récent Mais en 2003, c'était ce genre de version que j'avais sous la main (ça gérait même pas les sous-requêtes !).
 
Pour la recherche de texte et sa complexité, oui, c'est un vaste sujet. D'ailleurs pour écrire mon algo d'analyse sémantique de tickets d'incidents (afin d'en proposer des similaires, identiques ou corréler déjà résolu), j'ai lu plusieurs thèses avant de commencer histoire de voir l'état de l'art, ce que j'étais capable de faire à partir de ces thèses, les pré-requis (genre, certains systèmes experts demandaient que les infos soient rentrées d'une manière supervisée, or moi, je voulais un algo non supervisé) et surtout, la puissance de calcul nécessaire compatible avec ce que j'avais à ma disposition.