2009-11-04 6 views
0

J'ai créé un écran de maintenance des personnes. Le client veut que je stocke la photo de chaque personne dans la base de données, et je l'ai fait sans problèmes. J'ai une table séparée pour les images avec deux champs, Id_person et Image.Performances dans les tableaux avec données/images binaires

Je suis un peu inquiet parce que c'est la première fois que je travaille avec des images dans une base de données. aurai-je des problèmes de performance quand la table se développe au-delà de 1000/5000 images? Je suppose que la taille de chaque image fera la différence. Je suis sûr que je devrai contrôler que l'utilisateur n'enregistre pas de très grandes images dans la base de données.

Quelle serait une bonne limite de taille? Le client n'a besoin que des photos du visage, mais je suis sûr que quelqu'un va essayer de faire les photos avec un appareil photo de "dernier modèle" en pleine qualité;)

Merci.

Répondre

1

Il est généralement préférable de conserver un dossier d'images et la base de données se réfère uniquement à ce dossier. Idéalement, chaque personne a un identifiant unique et les fichiers du dossier "images" correspondent à cet identifiant.

Si vous voulez vraiment stocker les données binaires directement, vous pouvez obtenir une photo de qualité raisonnable en 8 Ko de JPEG (environ 250 x 250 pix @ 25% de qualité). Bien sûr, ce serait inacceptable pour l'impression, mais c'est bien pour l'identification.

Seulement vous saurez si vous pouvez accepter 8 Ko supplémentaires par ligne dans votre serveur de base de données.

+0

Je suis complètement d'accord avec vous ... Mais le client veut les photos enregistrées dans le serveur DDBB. – Jonathan

+1

Vrai ... Je viens d'ajouter un petit texte pour répondre à cela. – jheddings

1

Si vous devez ABSOLUMENT le faire de cette façon, je dirais limiter à quelques kilo-octets chacun. Cependant, chaque administrateur de base de données dans le monde vous dira probablement que les images de blobing dans un champ de base de données sont une très, très mauvaise idée. Le plus notablement, vous verrez les performances diminuer considérablement lorsque le fichier de base de données dépasse la taille de deux gigaoctets. Je préfèrerais faire comme jheddings dit et avoir un dossier avec l'ID de chaque personne soit le nom du fichier et juste utiliser un .jpg standard ou quelque chose après cela sur un partage réseau afin que tous les ordinateurs utilisant l'application puissent accéder aux images. Certains trouvent que la simple utilisation de l'ID n'est pas assez bonne, la photo doit être supprimée ou archivée, auquel cas ils vont mettre un champ NVARCHAR (MAX) dans leur base de données et stocker le chemin du fichier réseau vers l'image au lieu de l'image réelle.

Je bloberais l'image uniquement si votre client ne peut absolument pas avoir un chemin de partage réseau.

+0

Je vais utiliser l'argument jheddings et l'alternative commentée pour essayer de persuader le client. – Jonathan

+1

Oui, vous devez limiter la taille du fichier pour empêcher les utilisateurs de télécharger des photos en taille réelle directement depuis un appareil photo. Mais, sur toute base de données moderne sur un système moderne, les grands espaces de tables/tables ne sont pas un problème. En fait, Microsoft Research a une étude qui dit que pour tout ce qui est inférieur à 256 Ko, il vaut mieux que le DB gère le stockage plutôt que le système de fichiers (research.microsoft.com/pubs/64525/tr-2006-45.pdf). Si même si leurs résultats sont en décalage de deux ordres de grandeur, c'est 64 Ko. – AngerClown

+0

Merci en effet pour le lien !! – Jonathan

0

tant qu'il est dans une table séparée avec ID | BLOB seulement il ne devrait y avoir aucun problème de performance pour récupérer cette photo, mais de l'autre côté je préfère garder dans DB uniquement les références aux fichiers sur hdd (ou mieux encore seulement la photo de l'utilisateur vous n'avez pas vraiment besoin d'une référence parce que l'utilisateur avec ID 1 va à /images/1.jpg)