Je suis responsable de certaines applications qui gèrent plusieurs To d'images. Nous avons constaté qu'il était préférable de stocker les chemins d'accès aux fichiers dans la base de données.

Il y a quelques problèmes :

• le stockage de la base de données est généralement plus cher que le stockage du système de fichiers
• vous pouvez accélérer l'accès au système de fichiers avec des produits standard prêts à l'emploi
  • par exemple, de nombreux serveurs Web utilisent l'appel système sendfile() du système d'exploitation pour envoyer de manière asynchrone un fichier directement du système de fichiers à l'interface réseau. Les images stockées dans une base de données ne bénéficient pas de cette optimisation.
• des éléments tels que les serveurs Web, etc., ne nécessitent aucun codage ou traitement spécial pour accéder aux images dans le système de fichiers
• les bases de données gagnent là où l'intégrité transactionnelle entre l'image et les métadonnées est importante.
  • il est plus complexe de gérer l'intégrité entre les métadonnées de la base de données et les données du système de fichiers
  • il est difficile (dans le contexte d'une application Web) de garantir que les données ont été vidées sur le disque du système de fichiers

Votre serveur Web (je suppose que vous en utilisez un) est conçu pour gérer les images alors qu'une base de données ne l'est pas. Ainsi, je voterais massivement pour le non.

Stockez uniquement le chemin (et peut-être aussi les informations sur le fichier) dans la base de données.

Je stockerais personnellement les données volumineuses en dehors de la base de données.

Avantages : stocke tout en un s'il vous plaît, accès facile aux fichiers de données, sauvegarde facile Inconvénients : Diminue les performances de la base de données, de nombreux fractionnements de pages, corruption possible de la base de données

Normalement, je suis fermement contre le fait de prendre la partie la plus coûteuse et la plus difficile à faire évoluer de votre infrastructure (la base de données) et d'y mettre toute la charge. D'autre part : cela simplifie considérablement la stratégie de sauvegarde, en particulier lorsque vous avez plusieurs serveurs Web et que vous devez en quelque sorte synchroniser les données.

Comme la plupart des autres choses, cela dépend de la taille et du budget attendus.

Deuxièmement, la recommandation sur les chemins de fichiers. J'ai travaillé sur quelques projets qui nécessitaient de gérer des collections d'actifs volumineuses, et toute tentative de stocker des éléments directement dans la base de données entraînait de la douleur et de la frustration à long terme.

Le seul véritable « pro » auquel je puisse penser en ce qui concerne leur stockage dans la base de données est le potentiel de facilité des ressources d'image individuelles. S'il n'y a pas de chemin de fichier à utiliser et que toutes les images sont diffusées directement depuis la base de données, il n'y a aucun risque qu'un utilisateur trouve des fichiers auxquels il ne devrait pas avoir accès.

Cela semble cependant être mieux résolu avec un script intermédiaire extrayant des données d'un magasin de fichiers inaccessible sur le Web. Donc le stockage DB n'est pas VRAIMENT nécessaire.

S'il s'agit d'une application Web, le stockage des images sur un réseau de stockage tiers, tel que le S3 d'Amazon ou la plate-forme Nirvanix, pourrait présenter des avantages.

D'après mon expérience, la solution la plus simple consiste parfois à nommer les images en fonction de la clé primaire. Il est donc facile de trouver l'image qui appartient à un enregistrement particulier, et vice versa. Mais en même temps, vous ne stockez rien sur l'image dans la base de données.

Les chemins d'accès aux fichiers dans la base de données sont définitivement la voie à suivre - j'ai entendu des histoires après histoires de clients avec des To d'images dire que c'était devenu un cauchemar d'essayer de stocker une quantité importante d'images dans un DB - le seul impact sur les performances est trop important.

Dans une entreprise où je travaillais, nous stockions 155 millions d'images dans une base de données Oracle 8i (puis 9i). 7,5 To d'une valeur.

Les petites images statiques (pas plus de quelques mégas) qui ne sont pas fréquemment modifiées doivent être stockées dans la base de données. Cette méthode présente plusieurs avantages, notamment une portabilité plus facile (les images sont transférées avec la base de données), une sauvegarde/restauration plus facile (les images sont sauvegardées avec la base de données) et une meilleure évolutivité (un dossier de système de fichiers avec des milliers de petits fichiers miniatures ressemble à un cauchemar d'évolutivité pour moi).

Servir des images à partir d'une base de données est facile, il suffit d'implémenter un gestionnaire http qui sert le tableau d'octets renvoyé par le serveur de base de données sous forme de flux binaire.