en général, on conseille justement de stocker les données dans une BD et les fichiers dans un FS qui est fait pour ça, c'est accédé + rapidement, et évite de mettre la base à genoux.
Evidemment, je confirme que ce choix est très généralement admis comme étant le bon. Concernant PhpWebGallery, je n'ai pas hésité, ce choix n'en était pas vraiment un.
Pour anecdote, lorsque le projet débutait, j'étais stagiaire dans une boîte d'édition de CMS (Content Management System) qui avait choisi de tout stocker en base, même les documents binaires (fichiers images, vidéos, documents PDF). J'avoue sincèrement que c'était à la fois complexe et particulièrement peu fiable.
Eventuellement, le seul avantage que je vois concernant le stockage des images en base concerne la sécurité : difficile d'obliger l'application à vous montrer une image à laquelle vous n'avez pas accès normalement (sauf bug dans l'application...). Il est de toute façon très possible d'interdire l'accès à un répertoire web en navigation directe... l'argument devient donc difficile à défendre.
il existe des galleries qui stocke tout dans le FS
En effet et je trouve ça plus propre, notamment pour les sauvegardes. Malheureusement, ce choix conceptuel freine les possibilités d'abstraction logique offerte par la base de données. Je ne dis pas que certaines fonctionnalités deviennent impossible à coder, mais qu'elle seront bien plus difficiles à implémenter et risque de faire chuter les performances.
A titre d'exemples, il est intéressant de pouvoir associer une image à plusieurs catégories sans dupliquer physiquement le fichier, de créer des catégories virtuelles logiques. Ce type de fonctionnalité est triviale avec une BD comme backend, lourd à implémenter avec uniquement un FS.
NB : je conçois parfaitement que ce type de fonctionnalité puisse être considéré comme inutile par certains.
[^] # Re: se passer du système de fichier... ou de la BD ?
Posté par Pierrick Le Gall . En réponse à la dépêche PhpWebGallery 1.4.0. Évalué à 3.
Evidemment, je confirme que ce choix est très généralement admis comme étant le bon. Concernant PhpWebGallery, je n'ai pas hésité, ce choix n'en était pas vraiment un.
Pour anecdote, lorsque le projet débutait, j'étais stagiaire dans une boîte d'édition de CMS (Content Management System) qui avait choisi de tout stocker en base, même les documents binaires (fichiers images, vidéos, documents PDF). J'avoue sincèrement que c'était à la fois complexe et particulièrement peu fiable.
Eventuellement, le seul avantage que je vois concernant le stockage des images en base concerne la sécurité : difficile d'obliger l'application à vous montrer une image à laquelle vous n'avez pas accès normalement (sauf bug dans l'application...). Il est de toute façon très possible d'interdire l'accès à un répertoire web en navigation directe... l'argument devient donc difficile à défendre.
En effet et je trouve ça plus propre, notamment pour les sauvegardes. Malheureusement, ce choix conceptuel freine les possibilités d'abstraction logique offerte par la base de données. Je ne dis pas que certaines fonctionnalités deviennent impossible à coder, mais qu'elle seront bien plus difficiles à implémenter et risque de faire chuter les performances.
A titre d'exemples, il est intéressant de pouvoir associer une image à plusieurs catégories sans dupliquer physiquement le fichier, de créer des catégories virtuelles logiques. Ce type de fonctionnalité est triviale avec une BD comme backend, lourd à implémenter avec uniquement un FS.
NB : je conçois parfaitement que ce type de fonctionnalité puisse être considéré comme inutile par certains.