Programmation.SQL : Stocker des photos dans une base de données
Posté par totof2000 () le 27 décembre 2007
0
Bonjour.
Est-il possible de stocker des photos dans un SGBD ?
En effet, j'ai lu des exemples de gestion ou de partages de photos, mais la plupart de ceux-ci ne stockent pas les images en BDD, mais seulement des URL vers lesdites images. Pourquoi?
Je vous remercie d'avance pour vos réponses.
> Lire le message (18 commentaires, moyenne: 1,6).
Vous avez demandé le commentaire #892384.
Run by 
Cette page a été générée par Templeet en 0.0576s (dont 0.0045 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Je suis pas un expert, mais ...
... oui c'est possible, en utilisant un champ de type BLOB (ou assimilé). Ça permet de stocker n'importe que contenu binaire.
Après, pourquoi ça ne se fait pas trop :
- c'est plus compliqué à mettre en place
- c'est plus lent quand la base est pas optimisée pour ça
- ça fait très vite grossir la base
- ...
En gros, c'est pour mieux séparer deux "types" de contenus aux caractéristiques différentes : les images prennent de la place, les données assez peu ; les données sont lisibles par un humain, pas les images ; les données sont plus souvent accédées que l'image (supposition); etc ...
Bref, je ne pense pas qu'il y ait de raisons complètement pertinentes, i.e. on trouve des partisans de l'un et de l'autre, c'est juste une question d'organisation.
[ Répondre ]
[^]Re: Je suis pas un expert, mais ...
- c'est plus compliqué à mettre en place
- c'est plus lent quand la base est pas optimisée pour ça
Ces deux arguments me paraissent censés
- ça fait très vite grossir la base
Bah, que ce soit la base ou un FS qui grossit, quelle est la différence ? Seraient-ce des limites imposées par le SGBD ou l'OS (style taille de fichier maximum sur un FS, limitation sur la taille des tables dans le SGBD, etc ) ?
De plus, je pense qu'il y a plus de risque de perdre de la place via les URL plutôt qu'en stockant les photos dans la base (moins de risque d'existence de photos n'ayant pas de lien vers l'appli - autrement dit des photos "orphelines").
[ Répondre ]
[^]Re: Je suis pas un expert, mais ...
>Bah, que ce soit la base ou un FS qui grossit, quelle est la différence ?
>Seraient-ce des limites imposées par le SGBD ou l'OS (style taille de fichier
>maximum sur un FS, limitation sur la taille des tables dans le SGBD, etc ) ?
Imagine que tu utilises un SGBD commercial célébre dans sa version gratuite. Dans ce cas, tu as des limites à la taille de la base gérée.
Un autre argument en faveur du stockage en base, c'est les sauvegardes : tu sauves juste ta base de données, et en cas de crash, ça remarche rapidement. Pas besoin de préciser à l'admin qu'il faut penser à sauvegarder tel répertoire en plus pour telle appli. Bref, en exploitation, c'est plus simple.
[ Répondre ]
[^]Re: Je suis pas un expert, mais ...
mwais... tu présentes donc l'utilisation de la SGBD comme solution pour pallier à un éventuel problème de coordination avec l'administrateur... pas génial... En plus, faudra tout de même le prévenir de l'explosion de taille de ta base de données (ou alors tu vas te chopper des problèmes de quotas)... De toutes façons, si tu ne fait pas confiance à l'admin pour faire des backups de fichiers, tu devrais faire encore moins confiance pour les DB, a fortiori avec des blobs...
[ Répondre ]
[^]Re: Je suis pas un expert, mais ...
ça se discute ... le souci, c'est qu'en cas de crash, tu vas restaurer chaque fichier corrompu de ta DB, quand bien même seul 5 % d'un fichier serait endommagé. Et un fichier de DB, ça peut devenir très gros, et restaurer un truc très gros, c'est trèèès long ... :/
En conservant les photos sur le FS, si 5 % du FS est naze, tu ne restaures que ces 5 % là.
[ Répondre ]
[+] [^]Re: Je suis pas un expert, mais ...
ça se discute. Je trouve l'approche "tout dans la base" assez simple. Une requête SQL, c'est quand même pas la mort.
Et la possibilité, avec un simple backup de la base, de tout sauver, puis de tout restaurer, c'est appréciable.
Par contre, ça implique d'accéder à ces fichiers en passant par la base.
Je vais parler de ce que je connais : PostgreSQL. Ça ne sera pas le cas, meme si le champ BLOB est dans la même table que des champs de description.
toujours pour PostgreSQL, ça ne prendra pas plus de place que si les fichiers sont stockés sur le disque dur. (en fait ça peut en prendre moins si on active la compression des champs binaires).
Sinon j'ai lu un peu le thread, et je n'ai pas vu l'argument clé en la faveur d'un stockage dans le SGBD, à savoir l'intégrité référentielle.
Si l'ajout d'un fichier échoue, on fait un simple rollback de la transaction et le tour est joué. Si le stockage est dans le filesystem, la gestion d'erreur devient plus complexe.
Néanmoins, tout ça est une question de point de vue. Si tu n'es pas allergique à l'anglais :
http://archives.postgresql.org/pgsql-general/2007-04/msg0019(...)
: y sont développés quelques arguments intéressants.
[ Répondre ]