Est-il approprié de stocker les fichiers image dans la base de données? Ou serait-il préférable de ne stocker que le chemin du fichier dans la base de données, tout en conservant le fichier lui-même sur le serveur?
Existe-t-il d'autres méthodes pour faire cela correctement?
Réponses:
Je vous conseille fortement de stocker les images dans le système de fichiers et non dans la base de données.
Le stockage d'images dans la base de données présente plusieurs inconvénients:
La base de données peut croître de manière inattendue. Parfois, l'espace est un problème. Par exemple, avec SQLServer express, vous avez une limite de 4 Go.
Les migrations de données peuvent devenir pénibles, par exemple si vous passez de SQLServer à Oracle
Les requêtes peuvent devenir très lentes et vous aurez une charge de base de données élevée
L'interopérabilité avec d'autres applications est meilleure si les images se trouvent sur le système de fichiers et si d'autres applications utilisent une base de données différente. Vous pouvez également y accéder directement et n'avez pas besoin d'outils de base de données.
Pire performance en général
De toute façon, vous devrez probablement créer des fichiers temporaires lors de la récupération des images de la base de données. C'est inutile.
Ces inconvénients dépassent de loin le coût de la synchronisation des chemins d'accès aux images stockées dans la base de données avec le système de fichiers. Il n'y a que quelques cas spéciaux dans lesquels il est préférable de stocker les images dans la base de données.
Recherche sur SQL Server 2005 et le système de fichiers NTFS (Microsoft) pour comparer les performances CRUD: vers BLOB ou non vers BLOB . Cette étude a également été réalisée dans une application web. Vous avez répertorié une autre base de données (MySQL) et je suppose que vous n'utilisez pas Windows Server pour votre site PHP, il serait donc intéressant si quelqu'un a fait une étude similaire sur différentes technologies.
Il s'avère que cela dépend de la taille des fichiers. SQL Server favorise (2x mieux) les blobs de 256 Ko ou moins et le système de fichiers privilégie les fichiers de 1 Mo +. Les systèmes de fichiers de cette étude gèrent mieux la fragmentation que la base de données, donc si vous mettez constamment à jour ces fichiers ou si ce système croît avec le temps, la fragmentation sera un facteur plus important pour le système de fichiers qui fera un meilleur travail.
Vous devez déterminer dans quelle mesure votre site est responsable de la maintenance de ces fichiers. Si vous créez un site pour que les agents des réclamations d'assurance téléchargent des photos d'un accident, vous feriez mieux de contrôler les transactions et de vous assurer que ces fichiers sont sur le serveur. De bonnes bases de données le font pour vous, donc en tant que développeur, vous avez ajouté de la pression.
La réplication, la sauvegarde, la reprise après sinistre, la fragmentation, la capacité de disque restante et les performances dans le temps doivent être prises en compte lors de la conception. Ce n'est qu'une étude sur la version précédente de SQL Server et, comme les autres fabricants de bases de données, je suppose que la gestion des fichiers volumineux et des binaires est un domaine concurrentiel majeur.
Si vous prévoyez d'avoir un grand nombre d'images, leur stockage dans une base de données peut supprimer les problèmes de manque d'inodes au niveau du système de fichiers.
Cependant, ce problème serait mieux résolu en utilisant un système de fichiers plus approprié et toutes les mesures recommandées avec ce système de fichiers sur l'organisation.
Sinon, le stockage d'images dans une base de données est un gaspillage complet de ressources. Enregistrez le chemin comme vous l'avez dit.