Indexation de répertoires et de fichiers

[bewidia]

Bonjour,

je cherche à remplacer une GED (Gestion de Documents) que nous utilisons intensivement mais à quelques pourcents de ses pleines capacités : en effet, elle nous sert actuellement à stocker des documents de manière hiérarchique (dossier, n sous-dossier, fichier), à rechercher par nom de document ou par date d'insertion et on profite du logiciel pour avoir des prévisualisations de documents Outlook ou autre.

Nous prévoyons de stocker les fichiers dans un coin et de les qualifier dans une base de données qui permettra de faire des recherches et de les télécharger/visualiser en faisant le lien avec le système de fichiers.

Nous développons jusqu'à présent en 4D, j'ai testé une petite structure avec une table unique qui contient un titre et quelques champs permettant d'effectuer des recherches et à partir de 800 000, 1 000 000 d'enregistrements, ça commence à sérieusement ramer (jusqu'à 2 ou 3 minutes pour chercher les enregistrements contenant un certain mot dans le titre).

Est-ce qu'il existe des BDD spécifiquement dédiées pour gérer cette problématique ? Les NoSQL orientées "document" type CouchDB ou MongoDB sont-elles la piste à creuser ?

Merci d'avance pour vos retours !

[mikedavem]

A voir la taille de vos documents mais SQL Server peut être un candidat dans votre choix de SGBD avec l'utilisation de la fonctionnalité FILESTREAM. Si vous êtes patient vous pourrez même utiliser SQL Server 2012 avec les FILETABLES.

++

[zOS19]

1 million c'est pas énorme quand meme, ca devrait être gérable par n'importe quel SGBD plus ou moins bien paramétré.

Par contre, pour faire des recherches full text ( like '%..%' ), il existe des trucs très biens, ce sont les moteurs de recherche (RetrievalWare, IDOL, etc...) qui sont spécialement faits pour ce genre d'opérations alors qu'un SGBDR n'est pas fait à la base pour ce type de recherche (même si certains comme SQLServer offre une pseudo fonctionnalité à peu près valable mais incomparable avec ce qu'on peut faire avec un vrai moteur de recherche)

[bewidia]

Merci pour vos participations !

Le but est de récupérer le contenu de la base actuelle (une arborescence) sur laquelle les utilisateurs ont effectivement l'habitude de faire des recherches "full text" (les utilisateurs créent par automatisme plus ou moins suivi un certain nombre de répertoires et les nomment d'une certaine façon) et de mixer avec une nouvelle structure dont le contenu sera indexé et structuré (l'utilisateur ne pourra plus créer de dossier, c'est une application qui le fera en fonction de paramètres)

Il faut évidemment que le passage soit complètement transparent pour l'utilisateur et que lorsqu'il cherche "robert", ça retourne tous les dossiers et documents dont le nom contient "robert", anciens et nouveaux. L'outil offrira une recherche indexée sur le nouveau contenu en plus.

Je teste depuis 2 jours CouchDB, ça a l'air intéressant mais l'impossibilité de chercher nativement le "contient" et de chercher par plusieurs clés m'embête un peu.

Pour reprendre l'existant, je crée les enregistrements

type : arborescence ou fichier
titre : nom_du_dossier
parent : id_du_dossier_parent

et pour les nouveaux

type : table1 ou table2 ou table3 ou table_n.
titre : nom_du_dossier
parent : id_du_dossier_parent
champ_specifique_1 : valeur 1
champ_specifique_2 : valeur 2
champ_specifique_n : valeur n

Et j'essaie de chercher en fulltext dans tous les enregistrements avec éventuellement des parametres indexés supplémentaires.

Si au vu des infos supplémentaires vous avez des idées qui vous viennent, je suis preneur !

Merci

[StringBuilder]

Avec SQL Server, en stockant les fichiers dans des varbinary(max) filestream et des index full text dessus, ça devrait passer sans problème.

Avec en plus la possibilité d'utiliser des recherches complexes sur des mots-clés présents dans les fichiers (le fulltext analyse les méta des documents, ce qui permet de rechercher non seulement dans le titre, mais aussi dans les informations du document (mot-clé, auteur, version, etc.) ainsi que dans le texte du document lui-même, ce qui est loin d'être inintéressant.

http://mikedavem.developpez.com/tuto...l-server-2008/

[StringBuilder]

Je corrige ce que' j'ai corrigé

SQL Server 2012 sait indexer les méta :
http://blogs.msdn.com/b/sqlfts/archi...nali-ctp1.aspx

Et là, ça devient vraiment intéressant.

[mikedavem]

Envoyé par zOS19

Par contre, pour faire des recherches full text ( like '%..%' ), il existe des trucs très biens, ce sont les moteurs de recherche (RetrievalWare, IDOL, etc...) qui sont spécialement faits pour ce genre d'opérations alors qu'un SGBDR n'est pas fait à la base pour ce type de recherche (même si certains comme SQLServer offre une pseudo fonctionnalité à peu près valable mais incomparable avec ce qu'on peut faire avec un vrai moteur de recherche)

Quels sont les fonctionnalités offertes par d'autres outils tiers et que SQL Server ne couvrerait pas ? Cela peut être intéressant de faire un comparatif.

++

[SQLpro]

Pour information, lisez l'article que j'ai écrit sur l'indexation textuelle dans les SGBDR selon la norme SQL. http://blog.developpez.com/sqlpro/p9...ext-search-no/
Vous verrez qu'il y a peu de chose que SQL Server ne sais pas faire comparer à Sphinx ou Lucene...
Il y a une comparaison entre MS SQL Server qui réalise presque toutes les opérations prévues par la norme et le fera toutes sans exception dans la version 2012...
En comparaison, la solution MySQL est plus que pauvre.

En sus rajouter à un SGBDR une couche externe d'indexation textuelle comme Lucène, veut dire deux serveur à administrer... Pensez à la complexité d'admin, d'autant que ces outils là ont rarement une IHM d'admin aussi riche que ce que vous aurez avec MS SQL Server !

A +