par David Jones
Utilisez la fonction de recherche documentaire de SQL Server 7.0 pour concevoir des bases de données pouvant être consultées sur le Web
Que vous fassiez des recherches pour un exposé ou que vous
recherchiez un numéro de téléphone, ou encore que vous ne fassiez que surfer,
vous utilisez probablement un moteur de recherche Internet quotidiennement. Pour
répondre à la demande d'informations récupérables, de nombreuses
entreprises conçoivent des sites Web utilisant des bases de données
relationnelles en arrière-plan et sur lesquels les utilisateurs peuvent
effectuer des recherches dynamiques. En notre qualité d'administrateurs de
bases de données et de développeurs d'applications, nous devons concevoir de
meilleurs mécanismes permettant à l'utilisateur de rechercher des informations
sur l'entreprise, telles que les bilans pour les actionnaires, les communiqués
de presse, les catalogues produits, etc... La fonction de recherche documentaire
de SQL Server 7.0 peut représenter la réponse. Le moteur de recherche
documentaire de SQL Server permet des recherches rapides, et offre des
fonctionnalités avancées de recherche de texte, très utiles dans un
environnement d'entreprise.
Vous utilisez
probablement un moteur de recherche Internet quotidiennement
Avec les premières versions de SQL Server, on était limité
à des requêtes sur de larges blocs de texte en utilisant LIKE dans une
instruction SELECT. Mais l'instruction LIKE est limitée, car elle ne peut
établir de correspondance qu'avec des séquences de caractères. En outre, si
on utilise l'instruction LIKE avec un signe pourcent (%) avant et après la
chaîne recherchée, on génère une analyse de table très longue. La plupart
des utilisateurs ont besoin de fonctions de recherche plus avancées, produisant
des résultats immédiats après qu'ils aient appuyé sur la touche Entrée.
Avec SQL Server 7.0 et les versions ultérieures, on peut toujours utiliser l'instruction
LIKE si on le souhaite, mais on peut désormais aussi utiliser une nouvelle
option de syntaxe et indexer les données.
Au lieu d'utiliser les index stockés dans la base de
données, le moteur de recherche documentaire utilise Microsoft Search Service
pour répertorier ces index sur le disque dur du serveur. Lorsqu'on sélectionne
l'option Full-Text Search dans la Configuration personnalisée de SQL Server, le
processus d'installation installe automatiquement Microsoft Search Service.
Toutefois, ce service n'est disponible que pour les systèmes Standard et
Enterprise sous Windows 2000 ou Windows NT, et non dans les versions poste de
travail ou Windows 9x. Microsoft Search Service intègre deux fonctions
distinctes : conception et peuplement du catalogue de recherche
documentaire, et traitement de la recherche.
Pour installer le moteur de recherche documentaire après
avoir installé SQL Server, il faut réexécuter l'installation à partir du
CD-ROM de SQL Server 7.0. Dans la boîte de dialogue Select Components
(Sélectionner les composants), sélectionnez L'option Full-Text Search, comme
cela est indiqué dans la figure 1, puis redémarrez. Seul SQL Server 7.0
fonctionnant sous NT Server prend en charge la recherche documentaire.
L'environnement NT Server Enterprise Edition clusterisé ne supporte pas encore
la fonction de recherche documentaire de SQL Server. De fait, Microsoft prendra
en charge cette fonction dans un environnement clusterisé dans SQL Server 2000.
Microsoft Search Service stocke les index de recherche documentaire dans des fichiers
situés sur un disque dur du serveur. Par défaut, Microsoft Search Service stocke
ces fichiers, appelés catalogues de recherche documentaire, dans \MSSQL7\FTDATA
mais on peut modifier le chemin d’accès de ces catalogues. On ne peut pas stocker
de catalogues de recherche documentaire sur une disquette, un lecteur réseau ou
un lecteur amovible. Les tables de grande taille ayant besoin d’espace, je crée
toujours les index de recherche documentaire dans une partition disposant de beaucoup
d’espace disque.
Pour utiliser l’indexation de recherche documentaire, la table SQL Server doit
disposer d’un index unique, également appelé clé primaire. S’il n’est pas possible
de créer de clé unique à partir d’une table potentiellement indexée, il faut ajouter
une colonne d’identité pouvant être incrémentée à la table, ou une autre colonne
permettant de créer un index unique. Pour aider Microsoft Search Service à fonctionner
de manière optimale, maintenez l’index unique aussi petit que possible. Après
avoir défini l’index unique, ou la clé primaire, on ne peut effectuer une indexation
de recherche documentaire que sur les colonnes char, varchar, text, nchar, nvarchar
et ntext.
Le moteur de recherche documentaire ne peuple pas dynamiquement les index de recherche
documentaire. Par conséquent, tous les ajouts, toutes les modifications ou suppressions
de données ne seront plus disponibles pour la recherche jusqu’à ce que l’on ait
à nouveau peuplé le catalogue de recherche documentaire. Il existe deux méthodes
pour peupler un catalogue de recherche documentaire à nouveau : faire un peuplement
manuel ou planifier une tâche permettant de peupler le catalogue. Ces deux méthodes
permettent de choisir entre un peuplement intégral et un peuplement incrémental.
Le peuplement intégral efface toutes les données stockées dans un catalogue de
recherche documentaire et le peuple de données liées aux tables correspondantes.
Etant donné qu’un peuplement intégral peut demander beaucoup de temps et de ressources
pour les tables de grande taille, je préfère utiliser un peuplement incrémental,
qui n’insère que les données textuelles ajoutées à la base de données depuis le
dernier peuplement incrémental. Pour effectuer un peuplement incrémental, l’une
des colonnes de la table de recherche documentaire doit être de type timestamp
(horodatage). Il n’y a pas de besoin d’effectuer le peuplement complet d’un catalogue
peuplé en incrémental tant que la définition de la table n’est pas modifiée, ou
tant qu’on n’a pas ajouté de tables au catalogue.
N’oubliez pas que les index de recherche documentaire ne sont pas aussi précis
que les index standard. Cependant, une recherche basée sur des index standard
ne renvoie que des résultats correspondant exactement à une chaîne de caractères
donnée, tandis qu’une recherche documentaire peut retrouver un mot, une expression,
le préfixe d’un mot ou d’une expression, un mot ou une expression proche d’un(e)
autre ou encore une désinence d’un terme (par exemple, une recherche sur « requête »
peut renvoyer les résultats contenant « requêtes », « requérir » et « requis »). Le
tableau 1, inspiré des informations contenues dans SQL Server BOL (Books Online),
répertorie d’autres différences entre les index SQL classiques et les index de
recherche documentaire.
Tableau 1 Index classiques et index de recherche
documentaire |
Index SQL classiques |
Index de recherche documentaire |
Stocké et contrôlé par la base de données |
Stocké dans le systeème de fichiers via la base
de données |
Plusieurs index par table. Automatiquement mis
à jour lorsque des données sont insérées, mises à jour ou supprimées. |
Une seule définition d’index par table. Il faut
faire une demande de peuplement (soit planifiée soit à la demande). |
Crées et supprimés en utilisant des instructions
SQL. |
Créés, gérés et supprimés en utilisant des procédures
cataloguées ou une interface utilisateur graphique |
On peut créer des index à partir de tout type
de colonne, à l’exception des colonnes de type texte, BLOB, binaire ou image. |
On peut créer des index uniquement sur des colonnes
de type char, varchar, text, nchar, nvarchar et ntext. Microsoft étudie
la possibilité de prendre en charge les types de données binaires dans les
versions à venir de SQL Server. |
Téléchargez cette ressource
Comment lutter contre le Phishing ?
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.
