Un petit article (de 20 pages quand même) sur le Full-Text de SQL Server. L’article complet est diponible ici :

Mise en oeuvre de la recherche Full-Text dans SQL Server 2005

Ici vous trouverez un script T-SQL d’exemple sur la base AdventureWorks : Script d’exemple.

Quelques morceaux choisis :

Création de l’index

[…]

Il faut indiquer au moteur d’indexation les éléments à indexer de la base de données. Les éléments que l’on indexe sont des colonnes. Pour cela on place un INDEX de type Full-Text sur la table en indiquant les champs, comme on ferait pour un index classique.

Dans l’exemple ci-dessous, on indexe la colonne Description dans la table ProductDescription :

CREATE FULLTEXT INDEX ON dbo.ProductDescription
([Description] LANGUAGE 0x40c)--French(France)
KEY INDEX PK_ProductDescription
ON NouveauCatalogue

Bien que la syntaxe soit ressemblante, les options diffèrent. Nous allons les détailler dans les chapitres suivants.

Il est possible de créer les index Full-Text sur des tables ou des vues mais ces dernières devront être indexées pour disposer d’une clé unique (cf. 3.2).

1.1 Langage

[...]([Description] LANGUAGE 0x40c [...]

Pour chaque colonne indexée, on peut (et je dirais même on doit) préciser la langue de cette colonne. Ce paramètre va permettre une indexation optimum car le moteur de recherche Full-Text va prendre en considération les spécificités culturelles du langage choisi. Ces spécificités impactent l’indexation elle-même et le requêtage du moteur de recherche.

Les modules sensibles à la langue choisie sont :

• Le Word Breaker : ce module se charge du découpage des mots dans un texte. Il est évident que l’on ne traite pas le chinois traditionnel comme l’espagnol
• Le Stemmer : ce module se charge de décliner les mots (pluriels, conjugaisons, etc.). Par exemple, ride va être décliné en rider, riding, rides, etc. en langue anglaise et fondre va être décliné en fondante, fondues, fond, etc. en français.
• Les Noises : ce module se charge de nettoyer le texte à indexer dans mots « polluants ». Ainsi, des mots comme le ou la (the, of, etc. en anglais), les lettres isolées ne seront pas pris en compte par le moteur.

Vous pouvez voir la liste des langages supportés par l’indexation Full-Text dans la vue système sys.fulltext_languages.

1.2 Clé unique

[...]KEY INDEX PK_ProductDescription [...]

Pour créer un index Full-Text, on doit préciser une clé unique. Une clé primaire ou un index unique peuvent être utilisés. Cette clé unique permet à l’indexation de faire référence à l’enregistrement contenant le texte indexé.

La clé unique est nécessaire pour que le moteur de requêtage puisse retourner les enregistrements correspondants aux résultats de la recherche.

[…]

Change Tracking

[…]

1.1 Modes de mises à jour

Une des problématiques rencontrées avec la recherche Full-Text est la mise à jour des index. En effet, on peut le voir dans l’architecture décrite plus haut, l’index Full-Text n’est pas stocké dans SQL Server, ce qui a pour conséquence qu’il ne soit pas mis à jour automatiquement quand on modifie ou que l’on insert des enregistrements dans la table.

Le Full-Text propose plusieurs façons de mettre à jour les index :

• Au fil de l’eau : c’est le CHANGE TRACKING
• Reconstruction complète : FULL POPULATION
• Incrémentale : INCREMENTAL POPULATION

Le premier choix peut sembler idéal car il permet d’avoir un index à jour en permanence. En effet, SQL Server se charge d’envoyer des requêtes de mise à jour au service d’indexation quand on modifie les champs indexés de la table. Mais ce mode comporte quelques contreparties, il entraine une consommation supplémentaire des ressources de votre serveur. Aussi, il peut y avoir une légère latence car l’envoi des requêtes se fait en asynchrone. Pour préserver les ressources, il est possible de ne répercuter les changements que manuellement par un job ou une requête.

Pour activer ou désactiver le change tracking, il suffit d’ajouter l’option suivante à la création de l’index :

WITH CHANGE_TRACKING { AUTO | MANUAL | OFF }

[…]