ç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.
c'est plus lent quand la base est pas optimisée pour ça
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.
ça fait très vite grossir la base
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.
[^] # Re: Je suis pas un expert, mais ...
Posté par Jean Meyrand . En réponse au message Stocker des photos dans une base de données. Évalué à -1.
ç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.