meilleures pratiques pour les recherches textuelles dans la base de données

Question

J'ai une application dans laquelle je dois effectuer une recherche dans divers champs textuels.L'application est développée en utilisant NHibernate comme ORM.

Je souhaite implémenter Porter Stemming dans les recherches, afin de pouvoir renvoyer des résultats pertinents même lorsque le mot-clé correspond à un mot similaire, par exemple la description d'un produit contient memories alors que le mot-clé de recherche est memory.

Quelqu'un peut-il suggérer les meilleures pratiques pour de tels types de recherches ?La première idée qui vient à l’esprit est de stocker deux versions du même champ dans une base de données, par exemple :

Description
Description_Search

Le Description La colonne serait le texte saisi par l'administrateur du site Web et est le texte visible sur le frontend.

Le Description_Search inclurait le même texte, mais passé par un algorithme de Porter-Stemming.Les requêtes de recherche seraient alors basées sur le Description_Search domaine, plutôt que Description.

Est-ce que ça a du sens?Est-ce une perte d'espace de devoir stocker deux versions d'un texte presque identique ?

Aussi, serait-ce Lucene.Net aider dans un tel cas ?J'envisage également d'intégrer Lucene.Net pour les recherches en texte intégral, mais je ne l'ai pas encore examiné en détail.

Merci d'avance!

Answer 1

Il n'est pas nécessaire d'utiliser deux champs pour cela, un seul suffirait.Un champ a deux "valeurs", dont une stockée qui peut être récupérée à l'aide de Document.Get(...), et un indexé utilisé pour la recherche.Il n'est pas non plus techniquement nécessaire de stocker les valeurs, une solution courante consiste à stocker un identifiant utilisé pour rechercher le contenu original dans une base de données.Cela vous permettrait également de rechercher plus d'informations, telles que les informations sur l'auteur et l'emplacement du document.

Lucene.Net serait utile dans ce cas, mais cela vous oblige à écrire vous-même l'infrastructure.Vous devrez vous occuper de la configuration des analyseurs (généralement rien à configurer) et indexer votre contenu.Comme mentionné dans un commentaire, vous pouvez opter pour la fonctionnalité de recherche en texte intégral de SQL Server, mais celle-ci présente certaines limitations (qui peuvent ne pas vous affecter).

Un gros problème que j'ai rencontré en utilisant le FTS de SQL Server, mais qui fonctionne dans Lucene.Net (ce n'est pas vraiment juste puisque vous pouvez presque tout faire dans Lucene.Net puisque vous écrivez le code qui le fait) est la sensibilité aux accents.Je n'ai pas pu le configurer en utilisant les règles de langue suédoise, où åäö doivent être traités comme de vrais personnages.Activer la sensibilité aux accents ferait cela, mais cela signifierait également que les signes diacritiques sont analysés comme de vrais caractères, ce qui signifie que ñ diffère de n.(Imaginez chercher un "jalapeno" et n'obtenez aucune correspondance pour "jalapeño").La désactivation de la sensibilité aux accents supprime essentiellement tous les signes diacritiques, ce qui åäö dans aao, et les mots s'avèrent complètement différents.

Écrire des éléments dans Lucene.Net (par rapport à SQL Server FTS) vous permet de mettre en évidence les résultats (présenter les phrases dans un document qui correspondent à la requête), de rechercher des documents similaires, de vérifier l'orthographe, d'améliorer les résultats personnalisés, de facettes et d'autres choses. cela améliorerait l'expérience de recherche de vos utilisateurs.