Stocker des images dans SQL Server?

J'ai créé un petit site de démonstration sur lequel je stocke des images dans une colonne d'image sur le serveur SQL. Quelques questions que j'ai sont ...

• Est-ce une mauvaise idée?

• Cela affectera-t-il les performances de mon site lorsqu'il se développera?

L'alternative serait de stocker l'image sur le disque et de stocker uniquement la référence à l'image dans la base de données. Ce doit être un dilemme commun à de nombreuses personnes. J'apprécierais quelques conseils et serais en fait heureux de faire moins d'erreur si je le pouvais.

Il existe un très bon article de Microsoft Research intitulé To Blob or Not To Blob .

Leur conclusion après un grand nombre de tests de performances et d'analyses est la suivante:

• si vos images ou documents ont généralement une taille inférieure à 256 Ko, les stocker dans une colonne VARBINARY de base de données est plus efficace

• si vos images ou documents ont généralement une taille supérieure à 1 Mo, leur stockage dans le système de fichiers est plus efficace (et avec l'attribut FILESTREAM de SQL Server 2008, ils sont toujours sous contrôle transactionnel et font partie de la base de données)

• entre ces deux, c'est un peu un toss-up en fonction de votre utilisation

Si vous décidez de placer vos images dans une table SQL Server, je vous recommande fortement d'utiliser une table séparée pour stocker ces images - ne stockez pas la photo de l'employé dans la table des employés - conservez-les dans une table séparée. De cette façon, la table des employés peut rester légère, moyenne et très efficace, en supposant que vous n'ayez pas toujours besoin de sélectionner la photo de l'employé, également, dans le cadre de vos requêtes.

Pour les groupes de fichiers, consultez Fichiers et architecture de groupes de fichiers pour une introduction. Fondamentalement, vous créez votre base de données avec un groupe de fichiers distinct pour les grandes structures de données dès le début, ou ajoutez un groupe de fichiers supplémentaire plus tard. Appelons cela "LARGE_DATA".

Désormais, chaque fois que vous avez une nouvelle table à créer qui doit stocker des colonnes VARCHAR (MAX) ou VARBINARY (MAX), vous pouvez spécifier ce groupe de fichiers pour les données volumineuses:

 CREATE TABLE dbo.YourTable
     (....... define the fields here ......)
     ON Data                   -- the basic "Data" filegroup for the regular data
     TEXTIMAGE_ON LARGE_DATA   -- the filegroup for large chunks of data

Découvrez l'intro de MSDN sur les groupes de fichiers et jouez avec!

Je suis tombé dans ce dilemme une fois et j'ai fait pas mal de recherches sur Google pour obtenir des opinions. Ce que j'ai trouvé, c'est qu'en effet, beaucoup voient mieux enregistrer les images sur le disque pour des images plus grandes, tandis que mySQL permet un accès plus facile, en particulier à partir de langages comme PHP.

J'ai trouvé une question similaire

MySQL BLOB vs fichier pour stocker de petites images PNG?

Mon verdict final était que pour des choses telles qu'une photo de profil, juste une petite image carrée qui doit être présente par utilisateur, mySQL serait mieux que de stocker un tas de pouces dans le disque dur, tandis que pour les albums photo et autres choses du genre, des dossiers Les fichiers / image sont meilleurs.

J'espère que ça aide

Je préférerais stocker l'image dans un répertoire, puis stocker une référence au fichier image dans la base de données.

Cependant, si vous stockez l'image dans la base de données, vous devez partitionner votre base de données afin que la colonne d'image se trouve dans un fichier séparé.

Vous pouvez en savoir plus sur l'utilisation des groupes de fichiers ici http://msdn.microsoft.com/en-us/library/ms179316.aspx .

Pourquoi il peut être bon de stocker des images dans la base de données et non dans un catalogue sur le serveur Web.

Vous avez créé une application avec beaucoup d'images stockées dans un dossier sur le serveur, que le client utilise depuis des années.

Maintenant, ils viennent à vous. Leur serveur a été détruit et ils doivent le restaurer sur un nouveau serveur. Ils n'ont plus accès à l'ancien serveur. La seule sauvegarde dont ils disposent est la sauvegarde de la base de données.

Vous avez bien sûr la source et pouvez simplement la déployer sur le nouveau serveur, installer SqlServer et restaurer la base de données. Mais maintenant, toutes les images ont disparu.

Si vous avez enregistré les images dans SqlServer, tout fonctionnera comme avant.

Juste mes 2 cents.

Lorsque vous stockez des images dans SQL Server, n'utilisez pas le type de données 'image' , selon MS, il est progressivement éliminé dans les nouvelles versions de SQL Server. Utilisation varbinary (max) à la place

https://msdn.microsoft.com/en-us/library/ms187993.aspx

Une autre option a été publiée en 2012, appelée Tables de fichiers: https://msdn.microsoft.com/en-us/library/ff929144.aspx

Bien que les problèmes de performances soient valables, les vraies raisons dans la pratique pour lesquelles vous devriez éviter de stocker des images dans une base de données sont pour des raisons de gestion de base de données. Votre base de données se développera très rapidement et les bases de données coûteront beaucoup plus que le simple stockage de fichiers. Les sauvegardes et les restaurations de bases de données sont beaucoup plus coûteuses et prennent du temps que les restaurations de sauvegarde de fichiers. À la rigueur, vous pouvez restaurer une base de données plus petite beaucoup plus rapidement qu'une base de données gonflée d'images. Comparez 1 To de stockage de fichiers sur Azure à une base de données de 1 To et vous verrez la grande différence de coût.

D'après mon expérience, stocker dans l'URL des images stockées dans un autre emplacement est le meilleur moyen pour un projet simple.