Quel SGBD choisir pour la recherche full texte ? [Résolu]

[camilleroux]

Bonjour,

Je participe actuellement au développement d'un site web permettant l'hébergement de documents texte (pdf, MS office, Open Office, ...). Je souhaite faire de la recherche plein texte mais uniquement sur les documents d'un utilisateur à la fois. Effectivement la recherche full text ne servira qu'à chercher parmis SES propes documents.
Le nombre de documents hébergés va devenir important (plusieurs millions, j'espère!). Il est a noter que les documents NE doivent PAS être sauvé dans la base. La base doit analyser le contenu du document (transformé en plein texte) et construire l'index. Enfin, je souhaite que dès qu'un utilisateur upload un document, celui-ci soit accessible immédiatement en recherche (pas de phase d'indexation périodique).
Je cherche une solution basé sur une base de données pour faire ses recherches.

Voici l'état de mes recherches:
MYSQL:
- La recherche Full Text est très lente dès qu'on utilise des clauses WHERE (indispensable pour avoir que les docs d'un utilisateur).
- impossible de créer une table ou une base par utilisateur pour des raisons de performance et de limitations par MySQL

SQLite:
+ permet de créer une BD par user
- Cette solution semble nécessiter le stockage du document dans la BD

Postgres:
- Cette solution semble nécessiter le stockage du document dans la BD

Solutions sans BD:
Lucene:
- nous souhaitons eviter de mettre JAVA sur les machines si possible
- pb de perf avec un grand nombre de documents si il y a qu'un seul index

Sphinx:
- indexation manuelle

[fadace]

Oracle, MS-SQL, Sybase ASE... tous ces SGBDR ont du FTS

[balmeyer]

Pour Postgresql, quel serait le meilleur outil de recherche full-text ?

[SQLpro]

rien ne vaut une indexation textuelle spécifique. En effet la norme SQL est trop cadrée sur le sujet et les solutions des éditeurs trop pauvres pour faîre ce que vous voulez.

Lisez donc l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/indextextuelle/

A +

[gregory.broissard]

au vue des attentes, du nombre de docs à indexer (millions), je suis d'accord avec SQLpro, je rajouterai même qu'il serait peut être pertinent de réfléchir à des vrais moteurs d'indexation FullText comme RetrievalWare par exemple, qui sont très puissants, performants et permettent beaucoup de choses (recherches thématiques par exemple...)