yN Moteur de recherche - Page 4

Recherche mise à jour pour pouvoir rechercher directement dans un forum sans tout selectionner.

J'ai aussi recalculé la base de recherche pour prendre en compte les titres d'avant aout 2007, car il n'y avait que les titres d'apres cette date qui étaient pris en compte.

onur (./81) :
Tu sors ça de la bouche de yaro? Parce qu'on ne m'a pas donné la possibilité de prouver le contraire, donc --> relecture.

pour tester, c'est trèèèèès simple, tu as déjà la moyenne de la taille des posts sur yN (cf les stats yN des années précédentes), tu as la taille, il te suffit de prendre plusieurs livres quelconque (parlant de deux/trois sujets) sur le net, le couper en morceaux plus ou moins gros selon la moyenne jusqu'à obtenir 2M de messages, tu mets ça en base, et à partir de là, tu auras de quoi faire joujou et nous montrer, avec les contraintes présentées plus haut, que ta solution est gérable.
Pour info, elle n'est pas la meilleure solution, surtout avec les contraintes proposées ici.
onur : au lieu de t'enteter dans une solution pour laquelle il me semble que le consensus actuel est de dire que l'indexation à la phpbb n'est pas convenable dans notre cas, pourquoi ne pas chercher à l'améliorer/modifier pour rendre ta solution plus sexy ?


Tiens, yaro, deux questions : combien de temps peut-on sacrifier en moyenne par post pour l'indexation (sachant qu'une indexation cronnée consomme du cpu, et donc, ralentit la création d'un post quand même), et en quel est le temps limite de retour d'un résultat de recherche ?

Puis il a ptêt autre chose à payer que yN...

Sans connaitre le modèle de données, et les choix d'arhitecture de la base, ça ne sert à rien de proposer un code php, aussi bon soit-il.
Comme nous n'aurons jamais ces infos...

Elles ont été données.

vince (./96) :
Elles ont été données.

...

Zephyr (./72) :
Bien tenté ^^

Foutage de gueule?

onur (./97) :
Foutage de gueule?

GUNNM (./95) :
Sans connaitre le modèle de données, et les choix d'arhitecture de la base

le "bien tenté" c'était parceque tu voulais les *données*, pas le *modèle* de données... comme a dit vince, il y a un bon paquet de trucs auxquels tu n'as pas à avoir accès sur yN, donc il est hors de question que tu aies le contenu de la base. et comme ça a été également dit, tu connais la structure, donc tu peux t'en recréer une avec n'importe quel contenu équivalent trouvé sur internet, c'est pas ça qui manque...

GUNNM (./96) :
Sans connaitre le modèle de données, et les choix d'arhitecture de la base, ça ne sert à rien de proposer un code php, aussi bon soit-il. Comme nous n'aurons jamais ces infos...

une table avec un champ qui contient les posts et un identifiant sujet, ca a été dit, répété et re répété ... tu veux quoi de plus ?

Sinon des modifications ont été apportées au moteur et bizarrement je n'ai eu aucun retour des personnes qui s'en plaignent ?

yAro (./99) :
une table avec un champ qui contient les posts et un identifiant sujet.

Une table posts, ça je vois, la table identifiant sujet, ça veux dire une clé externe vers une table 'sujets'? Et je suppose que tu as un champ contenant une clé externe vers une table 'utilisateurs'?

Zephyr (./98) :

onur (./97) :
Foutage de gueule?

GUNNM (./95) :
Sans connaitre le modèle de données, et les choix d'arhitecture de la base

le "bien tenté" c'était parceque tu voulais les *données*, pas le *modèle* de données... comme a dit vince, il y a un bon paquet de trucs auxquels tu n'as pas à avoir accès sur yN, donc il est hors de question que tu aies le contenu de la base. et comme ça a été également dit, tu connais la structure, donc tu peux t'en recréer une avec n'importe quel contenu équivalent trouvé sur internet, c'est pas ça qui manque...

évidemment je voulais pas la partie à la quelle je n'ai pas accès, ca me semblait évident

en cherchant "trou du cul lapin" et en sélectionnant humour et blagues, le premier résultat est du forum général

GUNNM (./102) :
Une table posts, ça je vois, la table identifiant sujet, ça veux dire une clé externe vers une table 'sujets'? Et je suppose que tu as un champ contenant une clé externe vers une table 'utilisateurs'?

les utilisateurs je vois pas le besoin ici, une table "id_post, id_sujet, post" suffit pr le pb

vince (./103) :
en cherchant "trou du cul lapin" et en sélectionnant humour et blagues, le premier résultat est du forum général

corrigé ^^

le probleme venait du mot lapin, ou du mot cul ?

aucun des 2, juste un bug

c'était lié au ./100 ?

nan, onur & co

Heu, moi je me plaind pas. Enfin plus depuis des années. Je n'utilise pas/plus le moteur de recherche.

si on cherche martine, y'a un post (de godzil, troisième résultat) qui est mal retourné...

topics/102943-martine#23

Ce que je comprends pas c'est que yaro veut absolument gérer le "OU" (qui pollue les résultats plus qu'autre chose à mon avis mais bon), à coté de ca, tous les mots qu'on recherche doivent faire au moins 4 lettres je vois pas trop la logique du truc.

Je pense que ton post "les utilisateurs ne connaissant rien aux contraites d'un systeme X ou Y je vois pas comment ils pourraient choisir " reflète bien ta philosophie. Tu réfléchis par tes contraintes à toi, et pas par ceux des utilisateurs.

tu connais google ?

google c'est OU par défaut, si tu veux autre chose, faut le préciser

onur (./113) :
tous les mots qu'on recherche doivent faire au moins 4 lettres je vois pas trop la logique du truc.

taille de la base tu connais ?

onur (./113) :
Tu réfléchis par tes contraintes à toi, et pas par ceux des utilisateurs

Bizarre hein, je prefere faire un truc qui peut fonctionner sur un serveur web et tenir dans une base de données mysql. Je dois etre bete et ne pas comprendre que c'est mieux de faire un truc qui plante

Entre ta méthode (ne rien faire, tout laisser à mysql) et la mienne (indexer à mort mais à la main) y a surement un milieu. Y a surement mieux à faire qu'idolatrer les géniaux ingénieurs de mysql qui ont fait cette indexation... générique que tu adores tant.

Parfois on peut se torturer la tete pour faire qq chose de bien, plutot qu'essayer de coller un truc "solution à tout" à son problème et se dire que c'est pas possible.

bah trouve un milieu alors.

onur (./116) :
Entre ta méthode (ne rien faire, tout laisser à mysql) et la mienne (indexer à mort mais à la main) y a surement un milieu. Y a surement mieux à faire qu'idolatrer les géniaux ingénieurs de mysql qui ont fait cette indexation... générique que tu adores tant.
Parfois on peut se torturer la tete pour faire qq chose de bien, plutot qu'essayer de coller un truc "solution à tout" à son problème et se dire que c'est pas possible.

Parce que tu crois que c'est la 1ere version du moteur ??? Il y en a eu une dizaine avant au moins, avec différentes méthodes ou j'indéxais plus ou moins manuellement et j'en ai déduit que le mieux est de laisser faire mysql, en tout cas si on utilise une base de données, surtout si on veut gérer la pertinence des résultats (scoring).

Sinon j'attend tjrs une proposition pour indéxer / rechercher sur une table (id_post, id_sujet, texte) de maniere rapide et sans que la taille dépasse le Go pour 600Mo de données ...

Pour info le fait de garder les mots de 3 lettres augmente la taille de la base dédiée à la recherche de 25% ...

C'est bien ce que je t'ai proposé. Le nombre de lettres indexées pour un mot est paramètrable et pourtant, contrairement à ta solution de facilité, ca gère la recherche dès la première lettre.

Je vois pas en quoi la structure de la table (id_post, id_sujet, texte) est un problème??? Je commence à me demander si tu as vraiment compris quelque chose à ce que je t'ai proposé. Dans la table ffs_asso, tu as une correspondance entre un mot et une entité, pour ton cas, entité c'est un couple (id_post,id_sujet).

Dernière chose: si la recherche est à sa 10ième version, c'est que tu as vraiment mis de la mauvaise volonté, vu son état.

J'ai pris le script que TU m'as envoyé et je l'ai executé en local et je n'ai jamais pu terminer l'indexation vu :

1- le temps que ca prennait
2- la taille de la base qui explosait

Tu réponds quoi à ces 2 arguments ?