Vous n'êtes pas identifié(e).
Pages : 1
Pour bien saisir la problématique, si j'ai les termes : "informer", "information", "informais", "informe".
Le lexeme produit par Postgresql dans ce cas là sera "inform" ?
Et ensuite dans le cadre d'un nuage de tags, quel serait le mot à faire apparaitre (du point de vue utilisateur) : informer ?
Et dans cette perspective, il faudrait donc associer un lexeme au mot générique représentatif de ce lexeme, un chef de file en quelque sorte.
Salut et merci pour votre réponse,
Sauf peut-être si je joue sur la configuration de l'indexation et que je n'affecte aucun dictionnaire/thésaurus dans le cadre de la "lexemisation" des termes ?
Et je pourrais avoir finalement 1 champs TS_VECTOR qui fonctionne normalement (avec la "lexemisation" sur la base de dictionnaires/thesaurus) pour ma recherche plein texte, et donc avec des racines de mots. Et un autre champs TS_VECTOR qui lui ne réduit pas les mots à une racine car je n'aurais configuré aucun dictionnaire/thesaurus.
Du coup dans ma table j'aurais 2 champs de type TS_VECTOR : un pour ma recherche plein texte et un autre en vue de mon nuage de tags.
Et pour lequel j'utiliserais la fonction ts_stat() sur ce dernier champs.
Fonction que je viens de découvrir et qui me donne exactement ce que je souhaite (la fréquence des termes en tout, et dans combien de document il apparait)
Ca le ferait ?
Y a t-il possibilité de configurer les dictionnaires/thesaurus, ou plus généralement indiquer à Postgresql de ne pas réduire les termes à leur racine, pour un champs ts_vector ?
Bonjour à tous,
Voilà je réalise en ce moment un petit cms et je voudrais également générer un nuages de tags sur la base du contenu des articles saisies.
Je travaille avec Postgresql.
J'ai pensé faire la chose avec Lucene en indexant le contenu de ma table article, et ensuite en récupérant la liste des tokens les plus fréquents (poids).
Mais ayant parcouru un peu la doc de Postgresql sur la recherche plein texte (FTS), je me dis qu'il est peut être possible de gérer entièrement avec Postgresql sans avoir de conséquences sur la performance.
Je me demande donc quelle est la bonne démarche à suivre pour gérer cela vec Postgresql de A à Z.
Si j'indexe le contenu de mon champs "article" (qui contient le corps de l'article) dans un nouveau champs de type ts_vector, j'obtiens les lexemes associés à mon article, et seulement à un article.
Mais ensuite, que dois je faire pour produire ma liste de token/lexeme global sur tous mes articles, avec les poids (ou fréquences) associés ?
Dois je avoir recours à une autre table ? Puis entièrement me reposer sur mon champs de type ts_vector dont je parle ci-dessus et qui "lexemise" le corps de mon article ?
N'y a t'il pas une fonction ou un mécanisme postgresql qui me permet d'avoir ma liste global de lexemes (à l'image de Lucene qui dispose d'une méthode pour avoir la liste global des tokens de l'index) ?
Et si oui, pensez vous que cela ait un coût sur les performances ?
Je me disais que si une méthode ou requête existait, il vaudrait peut être mieux produire un fichier xml des lexemes (par une espèce de batch par exemple, toutes les nuits) plutôt que de faire à chaque fois une requête sql à chaque chargement de page (sachant que le nuages de tag serait affiché éventuellement sur chaque page web du site) ?
Par avance, merci pour votre aide
Pages : 1
