En fait, cette solution est très peu utilisée, car jusqu'à la 9i, Oracle Text Search était connu sous le nom de InterMedia Text. Et ce petit module coûtait aussi cher que Oracle tout seul, donc forcément, il n'était pas souvent implémenté. Maintenant, c'est chose réglée, grâce à Microsoft (et oui) qui a intégré son Freetext Search dans SQL Server 2000 sans supplément de license, Oracle s'est senti obligé de suivre avec la version 9i, pour le grand bonheur de tous
Il faut ajouter à ça un avertissement cependant.
De la même façon que Microsoft recommande une machine super-puissante pour faire tourner son Freetext Search, Oracle Text Search est lui aussi très consommateur.
Pour ce qui est des requêtes elles-même, c'est plutôt léger, ça ne consomme que très peu.
Par contre, la place utilisée par les index est monstrueuse : le moteur se crée un dictionnaire de tous les mots trouvés dans toutes les lignes indexées, avec une chiée d'informations, telles que les différentes positions du mot pour chaque occurence, des informations linguistiques permettant de trouver des mots de même radical ou synonymes...
Les index sont par conséquent extrêment douloureux pour le serveur à reconstruire. Au point qu'ils ne se reconstruisent pas seuls ! Lorsqu'on ajoute une ligne dans la base, il ne se passe rien au niveau de l'index. Par contre, si on modifie une ligne, ou qu'on la met à jour, cette dernière est simplement supprimée de l'index, pour s'assurer que les résultats retrouvés sont cohérents !
Il faut donc, par tâches schédulées et plans de maintenance interposés, regénérer les index à interval régulier.
Côté administration du serveur Oracle, ce n'est pas moi qui m'en occupe du tout (c'est ça de bosser pour une multi-nationnale), par contre, pour ce qui est de SQL Server (que j'utilise chez moi et dans mon agence), il y a heureusement plusieurs systèmes de mise à jour de l'index. Généralement, on choisi une indexation incrémentielle avec un interval très court (une demi-heure ou une heure), puis une réindexation complète journalière par exemple.
Je n'ai jamais eu l'occasion de gérer des bases très volumineuses avec SQL Server (le plus que j'ai fait, c'était 180 Mo...), donc je n'ai jamais senti la charge du serveur (il pédale quelques secondes en tout en pour tout). Mais avec une base de plusieurs Go, et une charge constante élevée, j'imagine qu'il faut à l'aise doubler les capacités de la machine si on veut conserver des performances correctes même pendant l'indexation, et éviter que cette dernière ne dure des heures...
Il faut bien garder en mémoire que ces fonctions sont à l'origine faites pour indexer des fichiers stockés dans la base, et pas des brides de bouts de texte comme sur un forum ou le site que je suis en train de faire
La mise en garde est donc à relativiser : on a vraiment un besoin important à condition qu'à la base on avait déjà un besoin énorme.
A noter que je ne sais pas si Oracle gère ça de la même façon que SQL Server, mais ce dernier est capable, lors de l'indexation de fichiers, de retrouver des informations dans les headers (PDF, fichiers Office, HTML, etc.) à propos de l'auteur, de la société émetrice, le résumé, etc. SQL Server est même capable de pondre lui-même un résumé du document (ça c'est bleuffant, parcequ'en plus c'est intelligible !)
J'ai vu qu'Oracle donne la possibilité de faire porter la recherche sur des nodes d'un fichier XML, donc je suppose qu'il est aussi capable des autres points que traîte SQL Server.
Bref. A bencher impérativement avant de choisir la solution, mais si elle répond aux besoins, oui, c'est réellement LE truc à faire pour faire un moteur de recherche.
Un exemple tout à l'heure :
SELECT SCORE(1) score, codpro, nompro
FROM search
WHERE CONTAINS(keyword, fuzzy('1A00473'), 1) > 0
AND CODLAN = 'ENG'
ORDER BY SCORE(1) DESC;
=> Moins de 200 ms. "fuzzy()" permet de recherche le mot et toutes ces variations de 2 lettres pour 7 caractères (paramètre standard)
Maintenant :
SELECT codpro, nompro
FROM search
WHERE CODPRO LIKE '%1A00473%'
AND CODLAN = 'ENG'
ORDER BY CODPRO;
=> Avec un index unique sur (CODPRO, CODLAN), et CODPRO varchar2(16)... Bah ça a duré 13 secondes, alors que le champ est pourtant indexé en cluster, et en plus le like ne porte que sur le pattern exact !
Bref, y'a pas photo, Text Search est infiniment plus puissant, pour un résultat infiniment plus rapide.
Message édité par Arjuna le 19-10-2004 à 23:25:11