Discussion :

[Arkham46]

[Access 2007 - Nouveauté] Champ Pièces-Jointes
Voici ce qu'on peut lire dans l'aide en ligne de la nouvelle version d'Access (trouvez la beta ici) :

Type de données Pièces-Jointes pour stocker des images, des graphiques, des fichiers Office, ou tout autre type de fichiers.
Le nouveau type de données Pièces-Jointes vous permet de stocker facilement tout type de documents ou fichiers binaires sans que la taille de la base de données ne gonfle inutilement.
Les pièces-jointes sont automatiquement compressées si cela est approprié pour optimiser l'espace utilisé. Vous avez besoin d'attacher un document Microsoft Office Word 2007 à un enregistrement? Vous voulez sauvegarder une série d'images numériques dans votre base de données?
Les pièces-jointes vous facilitent grandement cette tâche. Vous pouvez même attacher plusieurs pièces-jointes à un même enregistrement.

Illustrations:

Affichage dans un formulaire :


Popup de gestion des pièces attachées :


Tests :
Augmentation de la taille de la base de données lors de l'insertion de fichiers :
1024ko pour une image Jpeg de 1004Ko
33880ko pour un document Pdf de 33702Ko
La taille du fichier intégré est quasiment identique à la taille de l'objet d'origine.
A noter que le compactage après insertion des fichiers n'a réduit la taille de la base de données que d'environ 4ko par fichier attaché.


Questions
- Avez-vous l'intention de l'utiliser pour y attacher vos documents?
- Si oui, dans quel type d'applications et pour quels type de documents?
- Au contraire pensez-vous continuez à stocker vos documents à l'extérieur de la base de données?
- Tout commentaire est bienvenu...

[Tofalu]

Un exemple d'utilisation :


A la découverte d'Access V12 : Les pièces jointes par l'exemple

[Maxence HUBICHE]

Rigolo, ce gadget ne me semble qu'être une évolution du champ Objet OLE.
Je pense que, pour ma part, je continuerai à recommander le stockage des path en champs texte, et l'affichage en dynamique.

et na !

[Le Pharaon]

Rigolo, ce gadget ne me semble qu'être une évolution du champ Objet OLE.
Je pense que, pour ma part, je continuerai à recommander le stockage des path en champs texte, et l'affichage en dynamique.
et na !

Je suis d'accord avec toi dans certains cas.

Mais quand il s'agira d'envoyer des informations (avec photo par exemple) sur un autre réseau on sera obliger d'utiliser les pièces-jointes

[Admin]

Non je continuerai a utiliser le module de Gaël Donat : FileIncluder
D'ailleurs le type champ pièce-jointe est pale imitation

Plus sérieusement, il est vrai que l'inclusion massif de document dans une base de données et pas forcément que Access n'est jamais très bon, je pense donc avoir la même utilisation que Maxence, cela dit mettre quelques fichiers (et pas 12000) pour faire une application deployable en stand-alone sans application tierce (type innosetup) peut-etre intéressant.

A voir.

[Maxence HUBICHE]

Je suis d'accord avec toi dans certains cas.

Mais quand il s'agira d'envoyer des informations (avec photo par exemple) sur un autre réseau on sera obliger d'utiliser les pièces-jointes

Bof...
Si vraiment tu sa besoin d'échanger, tu mets tes fichiers sur un serveur ftp.
A partir de là, rien ne t'empèche de retrouver le fonctionnement que je décrivais.
non ?

[argyronet]

Mmmm, tout à fait d'accord avec

Rigolo, ce gadget ne me semble qu'être une évolution du champ Objet OLE.
Je pense que, pour ma part, je continuerai à recommander le stockage des path en champs texte, et l'affichage en dynamique.

et na !

Comme tu dis, na !

[guiblan]

Salut !!

Je souhaiterais répondre aux personnes qui pensent qu'ils ne faut pas mettre les fichiers dans la base de données.

Je travaille en général sur Oracle pour mon boulot et on a des blobs qui sont remplis avec des images, des pdfs et autres documents. L'application qui le gére est une appli web.

Alors il faut savoir comment sera utiliser la base de données pour savoir si cela vaut le coup.

Je vais utiliser le champ "piéce jointe" car la base de données va circuler entre plusieurs personnes et que des photos doivent être vu facilement.
Je suis le seul informaticien qui a la capacité de modifier et de créer un package si les fichiers sont externes à la base.

Donc c'est une affaire d'utilisation.

Cdlt,
Guiblan

[Maxence HUBICHE]

Ouaip !
Mais, d'un autre côté, une base de données Access a une taille limitée.
Alors, si tu stockes des images, des documents, des etc. tu vas faire grossir de manière exponentielle ta base de données. Donc...

Comme tu dis, après, c'est une question d'utilisation.
Donc, si jamais tu as une base avec 50 images de 50Mo, t'es déjà à 250Mo (au moins) rien que pour stocker les images.
Sur une taille max de 2 Go, ca fait moyen !
Mais bon... c'est vrai que là, ca passe.
Maintenant, si tu fais une base de plusieurs milliers, voire centaines de milliers de lignes (ce qui devrait être plutôt fréquent pour une base de données) alors là, l'usage des pièces jointes se trouve très vite limité non ?

Qu'en penses-tu ?

[Le Pharaon]

Donc, si jamais tu as une base avec 50 images de 50Mo, t'es déjà à 250Mo (au moins) rien que pour stocker les images...

Tu voulais dire 5 Mo ?

[Maxence HUBICHE]

oui...
oups !
j'ai bavé

[guiblan]

Salut !!

Dans mon cas, en ce moment, j'ai des images jpeg de 5ko donc je vais pouvoir en mettre.

La base de données est pour gèrer une association au niveau des membres et du matériel. Il n'y aura pas 5000 adhérents d'un coup donc il y a de la marge pour stocker les photos.

Comme nous sommes plusieurs à travailler sur la base finale ( responsable du matériel, trésorier, président et les initiateurs) il faut donc un système centralisés sans internet (certaines ne l'ont pas ).

Donc il faut avoir les images dedans.

Au départ j'avais pensé prendre une base de données MySQL avec un programme java mais OpenOffice Base marche assez bien. Le problème est au niveau des sous-formulaires qui ne sont pas utilisés comme pour Access.
Avec cette nouvelle fonctionnalité, j'ai pris la décision de tester la faisabilité de ce projet sous Access 2007.
C'est pour cela que je pense que dans certains cas précis, le stockage des images ne pose pas de problèmes.

Cdlt,
Guiblan

[Tofalu]

Cela ne justifie pas non plus un champ de type pièce jointe ici.

Car ton appli pourrait trés bien être non pas un fichier mdb mais un fichier mdb et un sous répertoire image. Cela ne change rien à la sauvegarde puisque de toute façon la taille de la base avec les images dedans et celle de l'ensemble du répertoire sont assez proches.

Il ne faut pas oublier non plus que avec une pièce jointe, si deux enregistrements ont tous les deux le même fichier, on le stocke deux fois dans la base alors que si le fichier est hors de la base on ne stocke que deux fois son chemin. Donc beaucoup moins place.

[Maxence HUBICHE]

j'ajoute que, même si, dans le cas que tu énonces (des images de 5Ko pour 5000 Enr.) ce n'est pas impossible d'utiliser la fonctionnalité, il y a exclusion (et toi-même tu le dit) des échanges via le net, puisqu'il faut un fonction centralisée de l'information, puisque certains n'ont pas le net et que 5000 * 5 = 25000K soit 25Mo !!! et ça, par mail... :s

Donc, si c'est centralisé, on retrouve l'intérêt de gérer les données dans une base de données et les fichiers par le système d'exploitation.

Bref, utiliser le marteau pour planter le clou et le tournevis pour visser, et pas l'inverse

[naphta]

Bonjour,

Voici mon expérience des PJ.

Il fallait accompagner dans les mails avec le devis et les commandes tout un lot de fiches techniques et autres.

Au début j'ai utilisé le champ pièce jointe mais à la longue des soucis sont apparus et avant que cela ne dégénère je suis passé à la gestion par le code d’une arborescence documentaire, on a plus de soucis et les utilisateurs sont satisfaits et la base aussi.

c'est, à mon avis, fait pour l'utilisation interne de la base pas pour faire de la ged.

a+