LupusMic

(laura) Insérer les images en base n'est pas forcément une mauvaise idée. Au contraire, une base de données est censée être faite pour cela.

(coringan) Les informations fournies par $_FILES ne sont pas fiable, car elles proviennent toutes du navigateur, sauf les clés tmp_name et error. Il faudra donc toutes les vérifier.

Premièrement la taille, avec filesize. Ensuite le type avec l'extension FileInfo disponible dans PECL. Et enfin le nom du fichier, qui est fournit par le client web. Ce nom est arbitraire, le client web peut donc fournir une chaîne d'attaque. C'est pourquoi il faut faire attention à son usage, voir l'ignorer.

D'ailleurs, je ne comprends pas l'usage de addslashes ici.

laura

(LupusMic) Pourquoi encombrer la base de données avec les données d'une image alors que tu peux la stocker sur le serveur? Je ne vois pas l'avantage pour un grand nombre d'images. Images un site avec 100 000 images de 300Ko

100000*300*1024= 30 720 000 000 octets rien que pour les images

Je n'ose imaginer les backups

Si c'est pour éviter qu'une personne accède aux images ou pour éviter le listage, un simple htaccess peut empêcher cela.

Puis des méthodes pour créer des noms uniques difficiles à trouver sont nombreuses donc j'ai un peu de mal à voir le gain que cela procure.

Personnellement, je ne stocke que les infos utiles : nom de l'image, date d'ajout, date de modification, image validée etc, etc.
Ça évite de trop solliciter la base de données pour "rien".

Quel avantage tires-tu de ta méthode?
As-tu un retour d'expérience sur cette méthode?

Je suis curieuse de savoir

LupusMic

La volonté de ne pas souhaiter insérer des données dans une base de données m'étonnera toujours.

Une base de données est conçue pour stocker des données, quelles qu'elles soient. Ce n'est pas une base de méta-données.

L'accès n'est pas la justification. Le premier argument est, je te l'accorde, dogmatique : les données sont stockées dans une base de données. Le second argument, plus prosaïque, est que la sauvegarde des données en est simplifiée. Puisqu'il n'y a qu'une arborescence à sauvegarder, à savoir le répertoire où MySQL sauvegarde les bases. Autre argument, la base de données peut être partagées entre différentes application. Conserver un seul point d'accès permet d'assurer cohésion des données. Sans compter que, puisqu'il n'y a qu'un accès, il n'est pas nécessaire de mettre à disposition un autre service internet (serveur de fichier). Réduire le nombre d'accès à une machine est un soucis permanent des adminsys.

Il y a bien sûr des arguments qui vont à l'encontre de cette méthode. Et là ça va vers des problèmes de performance : Apache ne peut plus gérer le cache des fichiers stockés en base. Il faut écrire cette gestion pour s'assurer que les images ne sont pas téléchargées à chaque fois, éventuellement écrire un cache qui permet d'éviter de télécharger systématiquement le fichier depuis la base de données.

Un article intéressant à lire au sujet de la gestion des images en base.

laura

Je suis d'accord sur le principe (une base de données stocke des données) mais en réduisant la charge du serveur de fichier, tu augmentes la charge du serveur sql.
Serveur déjà très sollicité dans un site dynamique (même avec un cache optimisé).
Le but de diviser en plusieurs serveurs étant de diviser la charge de travail pour éviter qu'un serveur soit down pour cause de surcharge.

De plus le serveur de fichier n'est pas systématiquement sollicité a cause du cache de données des navigateurs modernes.

Alors qu'une page dynamique qui possède les images en bdd sera toujours sollicitée (ou presque) dans ton programme.
Un autre petit point, l'utilisation du base de données pour cela va augmenter la conso de ressource système car l'image sera stockée en RAM comme de la données brutes pendant un bon laps de temps.
Je pense qu'il y a des pours et des contres aux 2 méthodes.
Je vais aller lire l'article en question C'est un sujet qui m'intéresse