Re: Avantages et inconvénients du stockage de fichiers en base

On lundi, 13 février 2017 15.51:14 h CET Sébastien Dinot wrote:
> Bonjour à tous,
> 
> Un collègue vient de me demander s'il était préférable de stocker des
> fichiers (de formats variés et d'une taille annoncée de quelques dizaines
> de Mo chacun) dans la base de données elle-même ou de ne mettre en base
> qu'un lien vers les fichiers, ces derniers étant stockés sur un système de
> fichiers conventionnel.
> 
> Je lui ai répondu que, d'expérience, j'aurais tendance à préférer le
> stockage externe pour plusieurs raisons (performance et taille de la base,
> efficacité de la sauvegarde, éviter d'avoir à se palucher la gestion de
> l'encodage dans le cas de fichiers de texte brut) mais, à l'issue d'une
> demi-heure de recherche sur le net, je n'ai trouvé aucune étude un peu
> poussée du problème sur le net.
> 
> La réponse la plus étoffée que j'ai trouvée est sans doute celle-ci :
> 
> http://softwareengineering.stackexchange.com/questions/150669/is-it-a-bad-pr
> actice-to-store-large-files-10-mb-in-a-database
> 
> Je devine que la question n'a pourtant rien de neuf et qu'elle a déjà été
> débattue des centaines de fois. Auriez-vous quelques pointeurs intéressants
> à partager ? Et, au passage, quel est votre propre avis à ce sujet ?
> 
> Je vous remercie par avance de vos lumières,
> 
> Sébastien

Je partage l'avis 
http://softwareengineering.stackexchange.com/a/150816

Tout va dépendre d'un ensemble d'éléments définis dans l'analyse du soft, de 
sa vie et de l'opérationnel.

J'ai un cas d'application qui génére un rapport (R plus graphique etc) en 
format odt puis transformé en pdf.
Je stocke le résultat en table cache (j'ai les différents formats à ma 
disposition après le traitement pourquoi sans priver).

Les données initiales ne sont pas toujours modifiés à la même fréquence, et 
donc le cache reste valide tant la donnée n'est pas modifier, évite la 
regénération (longue).

Pour la consultation, une simple requête récupére les données désirés au 
premier aller retour dans la db.

Un système de cache sur filesystem pourrait tout aussi bien faire l'affaire,
mais compliquerait l'application, en cas de trigger de mise à jour d'une 
donnée, aller nettoyer le système de fichier? Je trouve cela moins propre que
l'invalidation de la ligne d'enregistrement dans ma table cache.
(Qui permet d'autre traitements statistiques etc)

Le volume général est faible entre 2 et 6Go donc pas impactant pour l'infra en 
terme de backup et replication.

-- 

Bruno Friedmann 
 Ioda-Net Sàrl www.ioda-net.ch
 Bareos Partner, openSUSE Member, fsfe fellowship
 GPG KEY : D5C9B751C4653227
 irc: tigerfoot




--
Envoi via la liste pgsql-fr-generale ([email protected])