Discussion :

[Msysteme]

Bonjour, j'ai une application gérant des clients, ces derniers ont des agences et l'application gere les photos de ces dernières.

Donc pour chaque client j'ai une 20 de photo de taille (environ4000ko)

le principe de stockage : j'ai crée un dossier dans le meme dossier ou je stocke la photo et le chemin de cette dernière est stockée dans la BD.

je souhaite avoir des idée pour optimiser ce que j'ai fait surtout en terme de taille des photos

Merci

[DotNetMatt]

le principe de stockage : j'ai crée un dossier dans le meme dossier ou je stocke la photo et le chemin de cette dernière est stockée dans la BD.

Déjà on note que tu n'as pas stocké tes photos dans la base de données, et c'est très bien !

je souhaite avoir des idée pour optimiser ce que j'ai fait surtout en terme de taille des photos

Tu peux retravailler les photos pour modifier par exemple leur taille (largeur et hauteur), tout en gardant les proportions. Le mieux c'est de conserver l'original de côté (par exemple si le client veut pouvoir récupérer sa photo quand il le souhaite), et de n'utiliser sur le site que les versions redimensionnées. Tu pourras trouver de nombreux exemples de code sur le net, en voici un.

[StringBuilder]

Déjà on note que tu n'as pas stocké tes photos dans la base de données, et c'est très bien !

Pas vraiment d'accord.

Autant sur les SGBD anciens et bas de gamme, le stockage de données binaires (donc images) est très peu recommandé, autant avec SQL Server (y compris Express) on trouve tous les outils pour stocker des images dans la base relationnelle sans pour autant plomber les performances de cette dernière.

On gagne alors grandement en :
- Simplicité de l'application : toujours bien plus simple de retrouver des données en faisant une jointure entre deux tables qu'en allant chercher sur le disque dur une arborescence stockée en base
- Meilleure intégrité : on ne perd pas de données dans une base de données. Sur un disque dur, oui. Idem, pas de données orphelines dans une base relationnelle
- Meilleures performances : si la base de données et les images ne sont pas stockées sur la même machine que l'application cliente, en un seul échange réseau on retrouve les images, alors que si on doit se palucher des accès UNC, c'est vite l'horreur
- Meilleure sécurité : plus facile de protéger les informations dans une base de données que dans un disque dur
- Simplicité de sauvegarde : une seule sauvegarde pour la base et les images. Plus simple pour restaurer des données suite à une panne, pas de déphasage.

Bref, investiguez du côté de FILESTREAM de SQL Server.

Sinon, pour réduire la taille physique de photos, pas 36 solutions :
- réduire la résolution (au dela de 2048x2048, c'est superflu, à l'impression on ne voit pas la différence sur du A5)
- augmenter la compression (format JPEG, PNG) : sur une photo correctement contrastée, on peut généralement compresser pas mal avant de voir apparaître des défauts visibles
=> Vous devriez pouvoir descendre à moins 500 Ko par photo sans perte visible en combinant les deux

PS : Avec les trigger CLR de SQL Server, on peut même combiner les deux. Lors de l'insertion de la photo (taille originale) dans la base, on peut réduire à la volée une version optimisée, et stocker les deux images, le tout de façon totalement transparente pour le programme C#.

[Pol63]

+1 pour "les photos en base c'est mieux"
(en plus c'est plus argumenté que "les photos en base c'est pas bien" ^^)

[DotNetMatt]

+1 pour "les photos en base c'est mieux"
(en plus c'est plus argumenté que "les photos en base c'est pas bien" ^^)

Chacun a son opinion sur ce point.

Personnellement je dirais que le système de fichiers est optimisé pour stocker des fichiers, tout comme le SGBDR est optimisé pour stocker des données relationnelles et gérer des ensembles de données. Donc oui FILESTREAM reste une très bonne option puisqu'il combine le meilleur des 2 mondes. Le stockage d'images en base n'a pas de sens puisque ces données ne peuvent pas réllement être exploitées par le SGBDR... Mais ici on ne parle pas du site de la FNAC, donc pas sûr que ca vaille la peine de rajouter de la complexité avec FILESTREAM, c'est pour cela que je ne l'ai pas mentionné ici.

En plus le stockage des images directement en base, cela oblige à toujours passer par le SGBD pour pouvoir y accéder (pas d'accès direct).

En tout cas dans les scénarios cloud, ou même en entreprise, stocker les images en base revient à augmenter le coût de ma base de données inutilement. Je préfère utiliser du stockage fichier (SAN/iSCSI) qui coûte bien moins cher, et donc FILESTREAM bien sûr. Autre bon point à noter pour Filestream, c'est le système de fichiers qui se charge de mettre en cache les données, ce qui laisse plus de mémoire (RAM) disponible pour gérer les requêtes. Donc là encore, on peut économiser et optimiser ses ressources.