Un tâche courante des applications Web est de rechercher des données dans la base de données en fonction de la saisie d’utilisateurs. Dans un cas simple, cela peut se limiter à filtrer une liste d’objets par catégorie. Un cas d’utilisation plus complexe pourrait impliquer une recherche avec pondération, catégorisation, mise en évidence, multilingue, etc. Ce document présente certains cas d’utilisation possibles et les outils pouvant être utilisés.
\nNous ferons référence aux mêmes modèles que dans Création de requêtes.
\nLes champs basés sur du texte offrent quelques opérations de correspondance. Par exemple, vous pourriez vouloir permettre de rechercher un auteur comme ceci :
\n>>> Author.objects.filter(name__contains="Terry")\n[<Author: Terry Gilliam>, <Author: Terry Jones>]\nIl s’agit d’une solution très fragile car elle exige que l’utilisateur connaisse une sous-chaîne exacte du nom de l’auteur. Une meilleure approche pourrait faire appel à une recherche indépendante de la casse (icontains), mais ce n’est qu’une petite amélioration.
Si vous utilisez PostgreSQL, Django fournit une sélection d’outils spécifiques à cette base de données pour permettre d’exploiter des options de requête plus complexes. D’autres bases de données ont des outils différents, parfois via des greffons ou des fonctions définies par les utilisateurs. Django ne les prend pas en charge pour le moment. Nous utiliserons quelques exemples tirés de PostgreSQL pour démontrer le genre de fonctionnalités que les bases de données peuvent offrir.
\n\nDans l’exemple ci-dessus, nous avons déterminé qu’une recherche non sensible à la casse serait plus utile. Quand on est confronté à des noms sortant de l’alphabet anglais, une autre amélioration possible est d’utiliser les comparaisons sans accents:
>>> Author.objects.filter(name__unaccent__icontains="Helen")\n[<Author: Helen Mirren>, <Author: Helena Bonham Carter>, <Author: Hélène Joy>]\nCela fait apparaître un autre problème, où nous cherchons des correspondances avec une autre orthographe du nom. Dans ce cas, nous obtenons toutefois une asymétrie, une recherche pour Helen trouvera Helena ou Hélène, mais pas l’inverse. Une autre option serait d’utiliser une comparaison par trigram_similar qui compare des suites de lettres.
Par exemple :
\n>>> Author.objects.filter(name__unaccent__lower__trigram_similar="Hélène")\n[<Author: Helen Mirren>, <Author: Hélène Joy>]\nNous rencontrons maintenant un problème différent : le nom plus long « Helena Bonham Carter » n’apparaît pas car il est bien plus long. Les recherches par trigramme envisagent toutes les combinaisons de trois lettres et comparent combien apparaissent à la fois dans les chaînes source et de recherche. En ce qui concerne le nom plus long, il y a plus de combinaisons qui n’apparaissent pas dans la chaîne source, ce qui explique qu’il n’est plus considéré comme une correspondance proche.
\nLe choix correct de fonctions de comparaison dépend ici du jeu de données particulier, par exemple en fonction des langues utilisées et du type de texte à rechercher. Tous les exemples que nous avons examinés portent sur des chaînes courtes et où l’utilisateur va probablement saisir un terme proche (selon plusieurs définitions) des données sources.
\nLes opérations de base de données standard atteignent leurs limites lorsqu’on est confronté à de gros blocs de texte. Alors que les exemples précédents peuvent être considérés comme des opérations sur une chaîne de caractères, la recherche plein texte examine les mots réels. En fonction du système utilisé, il est probable que certains des concepts suivants seront utilisés :
\nIgnorance des « mots vides » tels que « a », « le », « et ».
Racines de mots, afin que « cheval » et « chevaux » soient considérés identiques.
Pondération des mots basée sur différents critères tels que la fréquence d’apparition dans le texte ou l’importance des champs (titre, mots-clés, etc.) dans lesquels ils apparaissent.
Il existe de nombreuses alternatives de logiciels spécialisés pour la recherche, dont Elastic et Solr sont parmi les plus célèbres. Ce sont des solutions de recherche basées sur des documents complets. Pour les utiliser avec des modèles Django, il sera nécessaire d’ajouter une couche de traduction des données en documents textuels, y compris des références inverses contenant les identifiants de base de données. Lorsqu’une recherche utilisant ces moteurs renvoie un certain document, il est alors possible de l’extraire de la base de données. Plusieurs bibliothèques tierces sont conçues pour vous assister dans cette tâche.
\nPostgreSQL possède sa propre implémentation de recherche plein texte. Même si elle n’est pas autant performante que certains autres moteurs de recherche, elle a l’avantage de se trouver dans la base de données elle-même et peut donc être facilement combinée à d’autres requêtes relationnelles telles que la catégorisation.
\nLe module django.contrib.postgres fournit certains utilitaires pour préparer ces requêtes. Par exemple, une requête pourrait sélectionner tous les articles de blog qui mentionnent « cheese »:
>>> Entry.objects.filter(body_text__search="cheese")\n[<Entry: Cheese on Toast recipes>, <Entry: Pizza recipes>]\nIl est aussi possible de filtrer sur une combinaison de champs et de modèles liés :
\n>>> Entry.objects.annotate(\n... search=SearchVector("blog__tagline", "body_text"),\n... ).filter(search="cheese")\n[\n <Entry: Cheese on Toast recipes>,\n <Entry: Pizza Recipes>,\n <Entry: Dairy farming in Argentina>,\n]\nVoir le document Recherche plein texte de contrib.postgres pour de plus amples détails.