Enregistrement d'images dans DB - réseau des applications de bureau

Question

connexes: Storing Images in DB - Yea or Nay?

Après avoir lu la question ci-dessus, il semble que la méthode préférée pour le stockage d'images avec des bases de données est de stocker uniquement CheminFichier dans la base . Cependant, la plupart de ces réponses semblent se concentrer sur les serveurs Web.

Dans mon cas, je développe une application de bureau qui sera utilisée sur plusieurs ordinateurs dans un intranet. Un serveur dédié hébergera la base de données, contenant des informations relatives à l'exécution de tests sur divers équipements.

Les images doivent être stockées sur le serveur d'une manière ou d'une autre. Le stockage des images dans la base de données serait-il l'approche correcte dans ce cas, voire la seule approche?

Plus:

• sauvegarde est limité à la base de données.
• Pas besoin d'ouvrir le système de fichiers du serveur sur le réseau.
• Protocole unique pour l'accès aux informations sur le serveur.
• Accès au fichier protégé. (L'utilisateur ne peut pas aller et supprimer toutes les images)

Contre

• Questions relatives à la performance à l'avenir s'il y a trop d'images.

Edit: Comme il est indiqué dans les balises, l'application est écrit en C#/NET.. Si l'écriture des images dans le système de fichiers est une option dans ce cas, je pourrais utiliser un peu d'aide pour comprendre comment cela est fait.

Edit 2: Comme nous le précisons certains dans les commentaires ci-dessous, pour l'instant je suppose une base de données MySQL, bien que les capacités FileStream de SQL Server 2008 pourraient changer.

Dans mon cas aussi, les images seront ajoutées souvent, et peuvent être considérées comme étant en lecture seule après ce point puisqu'elles ne devraient jamais être changées, et seront simplement lues si nécessaire. Les images seront probablement petites (~ 70k chacune), et j'envisage également d'autres formats de stockage binaire sur le serveur, des fichiers de ~ 20k chacun que je peux probablement appliquer de la même manière pour stocker et récupérer.

Answer 1

Je pense que la réponse est qu'il n'y a pas de bonne réponse. Comme avec la plupart des choses dans la programmation (et la vie), DEPENDS.

Voici quelques avantages et les inconvénients de stockage dans DB:

PROS

• sauvegarde facile, gestion et un guichet unique pour les données dans votre application
• Moins dépendances dans votre application et moins de pièces mobiles. KISS Principe
• Fonctionne correctement sur les petits fichiers de moins de 1 Go.
• Hey c'est un DB, donc les sauvegardes peuvent être effectuées à l'intérieur des transactions et annulées en cas de problèmes réseau
• Sharepoint et TFS stockent tout dans la base de données et fonctionnent très bien. même les grands garçons font
• La sécurité peut être facilement contrôlé par l'application et ne pas impliquer les autorisations fichier/dossier

Contre

• Mange l'espace db
• potentiellement effet performance si ce n'est pas fait correctement
• Pas une bonne idée si vous stockez toujours de gros fichiers (> 1 Go) sauf si vous utilisez Filestream dans SQ L Server 2k8
• Nécessite de mettre en œuvre une stratégie de mise en cache décente (même si vous le voudriez probablement de toute façon)
• Système de fichiers plus naturel que la base de données et plus facile à remplacer/visualiser manuellement les fichiers.

Je suppose que quand il vient à votre situation, je pencher vers la simplicité de stockage dans le DB.

Answer 2

Si vous pouvez utiliser Sql Server 2008, un coup d'oeil à ce lien

Saving and Retrieving File Using FileStream SQL Server 2008

Answer 3

Combien d'images parlons-nous? Sont-ils uniques/mis à jour fréquemment? Si non, pouvez-vous empaqueter les images avec le client que vous allez distribuer à plusieurs ordinateurs? Personnellement, j'éviterais de stocker des images dans la base de données, et à la place, comme vous l'avez dit, de stocker les chemins de fichiers.

Si vous avez lu toutes les autres questions similaires (This, this et this) mais demandez encore si cela est une bonne idée, alors peut-être votre problème est assez différent que ce serait une bonne idée.

Answer 4

Je suggère de conserver ces fichiers sur le disque dans le système de fichiers plutôt que dans la base de données. Système de fichiers pour les fichiers, bases de données pour des données relationnelles, etc.

Livrer par Web Service

Tenir compte livrer ces images à votre application de bureau en accueillant un service Web/app sur cette machine DB. Le travail de cette application est de ne servir que des images. Configurez un serveur Web sur cette machine avec une application ASP.NET. Avoir un .ashx gérer les demandes et diffuser l'image binaire. Quelque chose comme ceci:

http://myserver/myapp/GetImage.ashx?CustomerID=123&ImageID=456

sécurité

Si la sécurité intranet est un problème, ce serait le point où vous pouvez faire en sorte que l'utilisateur est authentifié et autorisé pour un accès en lecture à l'image. Les pistes d'audit pourraient également être implémentées ici.

sécurité du système de fichiers

En ce qui concerne la sécurité sur ces images, considèrent que NTFS vous donne beaucoup de mesures pour garantir que seules les personnes autorisées peuvent lire/supprimer/mettre les fichiers. La tâche consisterait alors à définir ces rôles et à implémenter des groupes de sécurité Windows.

besoins futurs

Cette approche vous permet de consommer en toute sécurité ces images partout sur l'intranet. Peut-être que cette application serait migrée vers une application Web à un moment donné? Peut-être une demande de fonctionnalité vient du client où une solution Web est appropriée?

Cela peut sembler exagéré plutôt que de lire un blob à partir de la base de données, mais c'est génial du point de vue de la sécurité. Tenez compte des attentes de vos clients et patients en matière de confidentialité et de sécurité.

<%@ WebHandler Language="C#" Class="Handler" %> 

public class Handler : IHttpHandler { 

public void ProcessRequest (HttpContext context) 
{ 
    //go to the DB and get the path for this ID. 
    string filePath = GetImagePath(context.Request.QueryString["ImageID"]); 

    //now you have the path on disk; read the file 
    byte[] imgBytes=GetBytesFromDisk(filePath); 

    // send back as byte[] 
    context.Response.BinaryWrite(imgBytes); 
} 

Answer 5

Si vous êtes à la recherche d'alternatives, l'un de mes favoris est un gestionnaire de téléchargement de fichiers HTTP POST dix en ligne (PHP, .NET, Java, etc.) + un serveur Web. Lorsque le script valide la taille maximale du fichier et extrait éventuellement la largeur & hauteur, il insère une ligne dans la base de données. La récupération n'a pas besoin de passer par le script. L'hébergement de fichiers standard fonctionnera. Cela vous obligerait à ouvrir le port 80. Vous n'avez pas besoin de compliquer cela avec SOAP ou quoi que ce soit. Un gestionnaire de téléchargement régulier ferait le travail.

Ensuite, il y a WebDAV, dans le même sens. Bien sûr, avec cette méthode, vous devrez surveiller le système de fichiers et ajuster la base de données en conséquence. Vous pouvez utiliser un service d'interrogation ou un hook dans les événements du système de fichiers. En fait, vous pouvez également injecter un filtre ISAPI ou un gestionnaire Apache pour effectuer les mises à jour de la base de données.

Vous pouvez utiliser FTP. Ajoutez une extension à ProFTPd qui mettra à jour la base de données et gardera tout synchronisé.

Nombreuses façons d'éviter de placer des données d'image dans des tables.

Si vous optez pour la solution de base de données, veillez simplement à segmenter vos objets BLOB dans des tables distinctes. Séparez les espaces de table/appareils/partitions, si vous le pouvez. Ou, utilisez Oracle et ignorez tout ce que j'ai dit.

Answer 6

Je ne pense pas que cela importe où les images sont stockées. Choisissez l'approche la plus simple qui fonctionnera. Mais vous devriez avoir une architecture où vous pouvez changer l'approche si elle s'avère être la mauvaise.

Pour ce faire, je mettrais les données et le stockage d'image à la fois derrière une interface de services Web. Choisissez une technologie - peu importe. Tous les accès aux données (et aux images) s'effectueraient de la même manière - via le service Web.

En faisant cela, vous avez découplé où les données sont stockées à partir de l'application de bureau. L'application de bureau ne s'en soucie pas. Tout ce qu'il sait, c'est que le serveur à une certaine adresse peut obtenir les données.

Puis stocker les données et les images où vous voulez. Choisissez la chose la plus simple pour vous. Si vous rencontrez des problèmes, alors (et seulement ensuite) vous devez ajouter une complexité supplémentaire pour résoudre le problème. Les bonnes nouvelles sont que la complexité et le travail supplémentaires ne devraient pas affecter les applications de bureau du tout. Vous pouvez effectuer les modifications sur le serveur sans avoir à déployer une nouvelle version des applications de bureau.

Answer 7

Du point de vue l'architecture , vous obtiendrez les meilleures performances en divisant la solution en deux parties: un serveur de base de données et un serveur d'images .

Vous le feriez tous les deux afin de réduire la taille des lignes et de séparer votre environnement transactionnel du contenu. Les bases de données relationnelles dans la veine de SQL Server et mysql supporteront les gros BLOB mais ne sont pas optimisées pour eux.

La plupart des gens assimilent «serveur d'images» au «serveur Web» parce qu'ils travaillent sur des applications Web et disposent donc d'un référentiel d'images de fait (un répertoire sur un disque local). Cependant, cela n'a pas avoir être le cas. Les images peuvent être servies à partir de n'importe quel endroit sur n'importe quel protocole.

Vous avez mentionné une plate-forme C#/.NET et un intranet. Pouvons-nous supposer un environnement Windows, éventuellement Active Directory?

Si tel est le cas, un serveur de fichiers ordinaire peut être votre serveur d'images. Configurer un partage de fichiers, définir les autorisations de lecture/création (mais pas modifier/supprimer) pour tous les utilisateurs de cette application, stocker le chemin UNC quelque part dans la base de données (donc vous ne devez pas redéployer l'application si vous décidez de relocalisez-le), et demandez à votre application cliente de générer un chemin relatif unique en utilisant quelque chose de fiable comme un Guid. Ce n'est pas aussi élégant qu'un service Web (ce qui est mon approche préférée), ni tout à fait aussi sans entretien que l'approche de base de données pure, mais mon impression de ce sujet est que vous êtes sur un budget serré avec un délai de livraison court, et un serveur de fichiers Windows ou NFS est moins cher, plus facile et plus rapide à installer et à maintenir (y compris les sauvegardes) qu'un serveur web à part entière, donc c'est peut-être ce que vous cherchez ici.

La plupart des entreprises disposent déjà d'un serveur de fichiers, ce qui ne nécessite généralement aucune nouvelle infrastructure. Mais même si vous ne le faites pas, j'ai vu des serveurs de fichiers fonctionner sur de vieilles stations de travail reconditionnées - ce n'est pas très sophistiqué, mais dans un environnement à faible trafic, le travail est fait.

Si vous choisissez cette approche, je suggérerais une sorte de structure de répertoire sur le partage de fichiers pour simplifier les sauvegardes, l'archivage, etc.Par exemple:

\\ImageServer\MyAppRepository\yyyy-mm\{image-file-name-or-guid}.{ext}.

Espérons que ça aide.

Answer 8

stockage Utilisez Amazon S3 pour vos images

magasin juste le GUID ou un autre nom de fichier dans le DB

Amazon est simple, rapide, pas cher. sécuriser etc etc

Il fines écailles, et fournit le cas échéant CDN comme les services de bord directement à partir de S3

images Stockage dans le DB semble toujours se transformer en un cauchemar au fil du temps

Answer 9

Il me semble que ce que vous vouloir faire quelque chose comme ce que font Infovark.

Ils utilisent Firebird pour cela et je vais vous donner un lien sur Firebird et storing image

Answer 10

Mon entreprise a développé une application Windows Forms C# qui stocke les images dans une base de données et cela a plutôt bien fonctionné. Nous l'utilisons activement depuis 2003 et avons environ 150 Go de données dans le système. D'abord, permettez-moi de dire que ce n'est pas l'architecture de performance optimale. Nous avons eu quelques problèmes avec la mise à jour des statistiques de la base de données et le bon réglage des index. Nous devons essentiellement ré-indexer le système tous les mois. Vous devez savoir que le système d'optimisation intégré de la plupart des serveurs SGBDR n'est pas configuré pour les grandes collections d'objets binaires.

La raison pour laquelle nous avons choisi de placer les images dans la base de données est due à la réplication au niveau de la base de données. Notre système est réparti entre sept bureaux dans cinq États et j'avais besoin de synchroniser les données sur chaque site. Donc, j'ai épinglé un VPN entre chaque site et notre siège social et mis en place la réplication de fusion SQL sur la base de données. De cette façon, je peux synchroniser les données et les images en même temps avec un seul canal ouvert entre les bureaux. Donc, je dirais que les images dans la base de données ne sont pas la solution optimale dans la plupart des cas, mais cela a fonctionné pour nos besoins.

Answer 11

vous devriez essayer MS SQl 2008, il est livré avec un Type: FileStream, qui stocke automatiquement blob dans le système de fichiers.