Indexer des fichiers dans une base

Bonjour j’espère que je suis le bien dans forum pour résoudre mon problème, si non dite moi ou je peux aller, en premier lieu je vais vous expliquer mon problème car j'avoue je suis un perdue :oops: :
-j'ai un dossier qui contient 2 sous dossier , chaque sous dossier contient des fichier pdf .
-je veux tous simplement créer une base qui contient ses dossiers mais le 1er problème consiste à transformer ses dossiers en bases de donnée j'ai réfléchie je pense avec access c'est mieux mais il faux tous d'abords les rendre en excel (l'outil pour le rendre en excel je n'ai pas trouvé qui le rendre comme ma structure de pdf c'est à dire il ne ne change pas mon contenue pdf)
-le 2eme pblm c'est de chercher dans cette base par exemple il vas tous d'abords le user entrer soit par nom ou par numéro donc on aura la recherche dans le 1er sous dossier si il trouve c'est bon on lui affiche quelle dossier ou se trouve dans notre cas le sous dossier 1 sinon il vas vers le deuxième sinon rien -> élément n'est pas trouvé

-donc pour résumer je bug un peux dans coté interface et base de donnée si on peu le fait avec java , aider moi s'il vous plais :oops:

Salut,

Tout ça n'est pas bien clair.

1. Tout d'abord, que veur dire "rendre un PDF" en Excel. Excel est un tableur, PDF un format de document (texte, images, etc). Que contient exactement le PDF ? Des tableaux de données que tu voudrais transformer en tableaux sous Excel ?
2. On ne stocke pas en général des fichiers dans une base de données. On stocke des informations du document, ou associées, et on stocke le fichier à part dans un système de fichier (dans la base, on stocke le moyen de retrouver le fichier dans la base (son chemin)).
3. Est-ce que le but est d'indexer des informations des documents PDF pour les retrouver rapidement. Dans ce cas, un indexeur, comme Lucène, ou Elastic Search par exemples, serait plus adapté. Mais on peut le faire aussi avec une base de données. L'indexeur permettra de faire plus facilement des recherches dans le texte, en mode fulltext.
4. Dans la base de données, il faut oublier la notion de dossier : la recherche sera globale. Pas besoin de faire une recherche dans un dossier, puis un autre.

Pour répondre à la dernière question, oui, on peut tout faire en Java :

1. récupérer/entrer des PDF, en extraire des informations, les stocker dans une base de données (j'opterais plus pour une base comme MySQL ou PostgreSQL, SQLlite, ou même H2, que pour MsAccess).
2. Faire des recherches, afficher les résultats, retrouver les PDF...
3. Faire une interface homme machine. Une première question est sur le type d'application : desktop ou web (dans un navigateur) ? Ensuite : standalone ou partagée (multi-utilisateur), donc client-serveur ?
4. Est-ce que c'est pour un petit projet, à faire rapidement, sans maintenance ultérieure, ni scalabilité à gérer (peu de PDF, volume faible..., nombre d'utilisateurs restreint), ou pour une application pérenne, nécessitant une architecture plus travaillée ?

"rendre un pdf en excel "c'est que mon pdf contient un tableau c'est pour cela j'ai voulu le rendre en excel , les informations du tableau de mon je veux chercher dont et les afficher pour le user c'est ça mon but .
-l'application est desktop .
-si c'est possible aussi la mise à jour(c'est a dire quand mes fichiers pdf change il faux que je vais la mise à jour ) .
mon problème je suis débutante en indexation je ne sais comment relier l'interface avec un moteur de recherche comme lucene ou sorl par exemple qui est pour la recherche c'est ça mon problème

donc il me faut un moteur utilisable qui m'aidera pour travaillez dessus

Donc si j'ai bien compris, les PDF ne représentent que des tableaux.
Ensuite tu me dis que l'application est Desktop, mais pas si c'est du client-serveur ou du standalone.

Premièrement, il faut absolument séparer les problématique, c'est plus simple à gérer. Après on choisit de gérer ou pas une problématique.

1. l'édition
2. la recherche
3. l'aspect fichier
   
   1. l'aspect PDF
   2. l'aspect Excel

1. Option 1. On gère des PDF. On indexe des PDF. On édite des PDF.
   On peut éditer directement des PDF.
   
   1. Il existe des applications, des SDK, des API, pour ça.
      Il n'y a même pas forcément Java dans la boucle. Mais l'intégrité des documents peut être compliquée à gérer voire ingérable : on peut saisir n'importe quoi, perdre l'intégrité du document...
   2. On peut contraindre de passer par une application pour l'édition. On simule l'édition du PDF par un moyen contrôlé, dédié.
      
      1. On peut utiliser une API orientée pour ça. Stocker, rechercher, éditer des documents se fait par exemple dans la suite Google. Il y a des API qui permettent de faire sa propre application. Je ne suis pas sûr qu'on puisse directement éditer du PDF, mais ça se vérifie.
      2. Tu peux faire une application qui assemble différentes API.
         
         1. Import/export
            
            1. On part du PDF (import), on le convertit, donc on en extrait les données et on les édite, puis on génère le PDF (export). On ne supprime pas nécessairement la possibilité d'entrer un PDF, mais il faut admettre que les documents saisis peuvent être rejetés parce que le format n'est pas conforme à quelque chose qu'on sait convertir en données.
               Ce genre de solution est compliquée et demande plus de travail de développement : faire des allers-retours PDF/données introduit forcément une problématique de contrôle.
            2. Excepté lors d'une phase initiale (reprise), on n'entre jamais un PDF dans le système. Cela évite d'avoir à développer des procédures complexes interactives d'import de fichier.
               On peut exporter un PDF. On peut stocker le PDF, mais uniquement comme cache, si c'est nécessaire. La recherche se fait sur des données : on est dans un paradigme classique.
         2. Édition
            
            1. L'édition se fait dans Excel. Dans ce cas, on peut aussi exporter un classeur Excel. Et importer un classeur pour le convertir en PDF.
               Mais on introduit des procédures de contrôle, du même genre qu'on avait pour le PDF, donc ça demande plus de travail de développement : faire des allers-retours Excel/données introduit forcément une problématique de contrôle.
               
               1. On peut rester complètement dans le paradigme Microsoft = Access + Excel + je ne sais quoi pour gérer l'import/export PDF (mais ça existe probablement). Cela ne concerne pas Java. Aller sur le forum VBA pour se renseigner.
               2. Passer par Java, pour faire des aller-retour PDF vers Excel et Excel vers PDF est possible, avec diverses API. Cela demande un travail de développement conséquent. La problématique de l'intégrité peut être complexe. Dans Excel, on peut faire n'importe quoi. Il y a des possibilités de border (limiter certaines actions), mais c'est un travail conséquent. Ou il faut être très directif envers les utilisateurs qui vont avoir des cas de rejet des fichiers importés.
            2. L'édition se fait via une application Java. Cela demande un travail de développement d'interface (JavaFX par exemple pour une application Desktop).
               On peut complètement éditer dans Java. La seule justification de Excel est que pour certains utilisateurs, ils sont habitués à ce logiciel. En revanche, si on veut arriver au même niveau de pratique qu'Excel dans une GUI Java, ça peut demander un travail de développement considérable. Tout dépend de la limite qu'on s'impose. Mais c'est faisable.
               Cela simplifie le stockage des données et la gestion de leur intégrité. On génère les PDF à partir des données. On peut stocker un PDF comme cache.
               Et on supprime toute problématique d'indexation de PDF.
               On a le choix :
               
               1. Faire ressembler l'éditeur à Excel
               2. Faire ressembler l'édition à celle d'un PDF (d'un document).
               3. Avoir une édition classique d'application d'édition de données (formulaires, tables, etc)
2. Option 2:
   Excepté lors d'une phase spéciale d'import , le PDF n'est qu'un format d'export. On utilise Excel pour l'édition.
   Voir les points 1 - 2, 1 - 2 - 2 - 2 - 1.
3. Option 3:
   On est dans une application Java d'édition de données avec export vers PDF.
   Voir les points 1 - 2, 1 - 2 - 2 - 2 - 2.

En ce qui concerne l'aspect recherche, à moins que des données à l'intérieur des documents doivent pouvoir servir de critères de recherche, on n'est simplement dans une recherche par le nom (ou une partie du nom). Inutile donc d'indexer des documents, même si on stocke des documents. Si on a des dossiers, on peut faire une recherche directe, à moins d'avoir des volumes importants. Sinon recherche SQL dans la base de données. A noter que si on a des volumes important de fichiers, le stockage par dossier est contre-indiqué, en particulier sur Windows (sur Linux/MacOS, je ne connaits pas assez pour en parler). Même si on stocke des documents en arrière plan (non accessible directement par l'utilisateur), comme cache par exemple, il faudra prévoir un hashage des dossiers.

Pour les API Java :

1. Apache POI pour les fichiers Excel
2. PDFBox ou iText pour les fichiers PDF

Pour l'indexation des fichiers, que cela soit par Lucene, SOLR, ELS..., il y a la documentation de ces produits pour savoir comment s'en servir.

si j'ai bien compris :
- si j'ai des fichiers volumineux il faux passer par l'indexation par Lucene,java,Solr...ect.
- sinon aller vers access et vba .
et concernant la taille des fichiers combien à peu près ?

Par volume, je parlais du nombre de fichiers. Pour le contenu, ça dépend si le contenu doit être indéxé ou pas. Toujours aucune information à ce sujet. S'il faut rechercher par du contenu, il faut indexer le contenu. Si on n'a pas besoin d'indexer le contenu, une base de données, voire une recherche sur du file système est adminissible (et ça, ça dépend si on utilise du file système ou de la base de données).
L'alternative entre VBA et Java ne dépend pas du volume, ni de fichier, ni de contenu.

merci beaucoup pour votre aide sa me donne une idée ;)