Enregistrer une image dans une base de données : BinaryFormatter vs ImageConverter

Le
Gilles TOURREAU
Bonjour,

J'ai besoin d'un petit conseil :

Je souhaite sauvegarder une image dans une base de donnée SQL Server.
Il faut donc convertir cette Image en tableau d'octets Byte[].

J'ai donc 2 solutions :
- Sois je sérialise l'image à l'aide d'un BinaryFormatter.
- Sois je converti l'image à l'aide de ImageConverter.

En testant les 2 solutions je remarque que la taille du tableau d'octets
obtenue n'est pas la même
La taille du tableau d'octets réalisé par la sérialisation est supérieure au
tableau d'octet fait avec ImageConverter.
Je pense que ceci est tout à fait normal vue que la sérialisation doit
convertir des champs supplémentaires dans la classe Image.
J'en déduis aussi que si je sauvegarde cette image à l'aide de la
sérialisation, il me sera donc impossible d'ouvrir cette image avec une
application autre que .NET

Est-ce que toutes ces affirmations sont-elles vraies ?
Quel solution me conseillerez-vous sachant, que les images présentes dans la
base de données seront certainement lue par des applications autre que .NET
?

En vous remerciant par avances de vos lumières

--
Gilles TOURREAU
Responsable Informatique
gilles.tourreau@pos.fr

Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Christophe Lauer [MS]
Le #12267841
Bonjour,

Gilles TOURREAU wrote:
Je souhaite sauvegarder une image dans une base de donnée SQL Server.
Il faut donc convertir cette Image en tableau d'octets Byte[].

J'ai donc 2 solutions :
- Sois je sérialise l'image à l'aide d'un BinaryFormatter.
- Sois je converti l'image à l'aide de ImageConverter.



Ou bien la troisième...

Quel solution me conseillerez-vous sachant, que les images présentes
dans la base de données seront certainement lue par des applications
autre que .NET ?



Vous pouvez également encoder vos images Bitmap (qui sont déjà un tableau de
Bytes, au passage...) au format Base64. L'intérêt de Base64 c'est que ce
format est supporté par la plupart des plate-formes car il correspond à un
RFC, le RFC2045.

Voir cet exemple en C# :
http://authors.aspalliance.com/nothingmn/default.aspx?whichpoll=nothingmn_121&aid1

Voir ici par exemple la doc en ligne PHP au sujet des fonctions
base64_decode() et base64_encode() :
http://www.php.net/manual/en/function.base64-decode.php
http://www.php.net/manual/en/function.base64-encode.php

HTH,

--
Christophe Lauer - Relations Techniques Editeurs de Logiciels
Division Développeurs et Plateforme d'Entreprise - Microsoft France
http://blogs.microsoft.fr/clauer/

This posting is provided "AS IS" with no warranties, and confers no
rights.
Merlin
Le #12267831
Une image n'est qu'un tas d'octets.. Toutes les bases de données ou
presque savent gérer des blobs binaires.
Il suffit donc de stocker l'image dans un blob de ce type. Certaines
bases disposent même de blobs spéciques image.

Ensuite les traitements divers et variés sont envisageables comme la
mise à une taille identique, la conversion vers un type de format (par
exemple toujours tout stocker en jpeg ou png..). Ce genre de choses
peuvent aider si la base est relue par d'autres logiciels (jpeg est
généralement connu de tous, png pas toujours, etc, un choix peut donc
être fait à ce sujet).

Quant à la sérialisation en effet je la déconseille : ça n'apporte rien
dans le contexte sauf : grossissement du fichier à stocker et
impossibilité de relire avec autre chose que .net.

Tu peux regarder le lien suivant qui explique comment lire et écrire
une image dans une base SQL Server en C# :

http://www.dotnetbips.com/articles/displayarticle.aspx?id`

--

///\3rL1n____
Simon Mourier [SoftFluent]
Le #12267811
Attention à la consommation mémoire et à la performance!

En règle générale, toutes les techniques qui passent par un unique tableau
d'octet (comme l'exemple ci dessous) ne sont pas bonnes, sauf pour des
petites images éventuellement.
En effet, si vous avez une image de 300M, vous allez allouer un tableau de
300M!

Il faut travailler sur des Stream de bout en bout (stream au niveau du
fichier, stream au niveau ADO.NET, ASP.NET dans le cas du web, etc...), avec
des boucles.

voir la fiche technique Microsoft ici
http://support.microsoft.com/kb/317016/EN-US/

qq articles
http://www.pcreview.co.uk/forums/thread-1237544.php
http://www.devx.com/vb2themax/Tip/19669

Simon.
www.softfluent.com


"Merlin"
Une image n'est qu'un tas d'octets.. Toutes les bases de données ou
presque savent gérer des blobs binaires.
Il suffit donc de stocker l'image dans un blob de ce type. Certaines bases
disposent même de blobs spéciques image.

Ensuite les traitements divers et variés sont envisageables comme la mise
à une taille identique, la conversion vers un type de format (par exemple
toujours tout stocker en jpeg ou png..). Ce genre de choses peuvent aider
si la base est relue par d'autres logiciels (jpeg est généralement connu
de tous, png pas toujours, etc, un choix peut donc être fait à ce sujet).

Quant à la sérialisation en effet je la déconseille : ça n'apporte rien
dans le contexte sauf : grossissement du fichier à stocker et
impossibilité de relire avec autre chose que .net.

Tu peux regarder le lien suivant qui explique comment lire et écrire une
image dans une base SQL Server en C# :

http://www.dotnetbips.com/articles/displayarticle.aspx?id`

--

///\3rL1n____




Merlin
Le #12267791
> Attention à la consommation mémoire et à la performance!



certes, c'est vrai qu'à partir d'une certaine taille les streams sont
préférables. Mais des images de 300 Mo, je ne sais pas si c'est très
intelligent de les stocker dans une base de données ...
On supposait ici que les images sont de tailles "raisonnables". Passé 1
Mo par image il faut certainement réfléchir au stockage (pas sûr que
dans le SGBD ça soit la meilleure solution).

--

///\3rL1n____
Daniel
Le #12267771
bonjour,

Pour m'a part je ne suis pas pour charger inutilement les bases de données.
je préfère faire l'upload de l'image dans un répertoire et mettre son nom
(généralement reformaté) dans le champ.

cordialement,

"Gilles TOURREAU" %
Bonjour,

J'ai besoin d'un petit conseil :

Je souhaite sauvegarder une image dans une base de donnée SQL Server.
Il faut donc convertir cette Image en tableau d'octets Byte[].

J'ai donc 2 solutions :
- Sois je sérialise l'image à l'aide d'un BinaryFormatter.
- Sois je converti l'image à l'aide de ImageConverter.

En testant les 2 solutions je remarque que la taille du tableau d'octets
obtenue n'est pas la même...
La taille du tableau d'octets réalisé par la sérialisation est supérieure
au tableau d'octet fait avec ImageConverter.
Je pense que ceci est tout à fait normal vue que la sérialisation doit
convertir des champs supplémentaires dans la classe Image.
J'en déduis aussi que si je sauvegarde cette image à l'aide de la
sérialisation, il me sera donc impossible d'ouvrir cette image avec une
application autre que .NET

Est-ce que toutes ces affirmations sont-elles vraies ?
Quel solution me conseillerez-vous sachant, que les images présentes dans
la base de données seront certainement lue par des applications autre que
.NET ?

En vous remerciant par avances de vos lumières...

--
Gilles TOURREAU
Responsable Informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr



Merlin
Le #12267731
> Pour m'a part je ne suis pas pour charger inutilement les bases de données.
je préfère faire l'upload de l'image dans un répertoire et mettre son nom
(généralement reformaté) dans le champ.



Pour des images de taille "raisonnable" le stockage ne pose aucun pb,
les SGBD sont prévus pour les blobs depuis des années, faut pas garder
des réflexes de programmation qui remontent à des lustres :-)

Sans rire, c'est étudié pour (peut être pas des blobs des 300 Mo comme
évoqué dans ce thread mais des photos jpeg de 100 à 800 Ko sans pb), et
surtout le stockage en SGBD est beaucoup plus sûr et fiable :

- intégrité des accès garantis (comment tu gères les accès concurrents
aux images dans un répertoire ? tout à la main avec les exceptions
système ?)
- garantie de synchronisation (comment tu gère sinon le fait qu'une
image est modifiée ou supprimée sur le disque pour que la base le sache
?)
- garantie de backup (la sauvegarde de la base sauvegarde aussi les
images)
- garantie de synchro des backups (si 1 sgbd + 1 répertoire il y avoir
désynchro des backups très difficiles à détecter et pire, desynchro des
restores).

- garantie de cohérence par les transaction si plusieurs entrées
concernant plusieurs images sont modifiées dans une session.

etc..

C'est pour toutes ces raisons que le stockage dans la base est toujours
à conseiller.
Le seul cas où cela commence à se discuter c'est si chaque image pèse
un poids délirant comme par exemple les 300 Mo évoqués.
Ponctuellement il peut, bien entendu, y avoir des cas très particuliers
ou le stockage en répertoire satisfait mieux le cahier des charges,
mais cela reste ponctuel.

--

///\3rL1n____
Simon Mourier [SoftFluent]
Le #12267671
La taille raisonnable maximum se situe entre 1 et 64k (la taille habituelle
des buffer pour streams). Au delà, les streams sont tout le temps
préférables.
Le stockage d'image en base de données ne pose aucun problème dans l'absolu,
si on le couple avec un cache sur disque.

Simon.
www.softfluent.com


"Merlin"
Attention à la consommation mémoire et à la performance!



certes, c'est vrai qu'à partir d'une certaine taille les streams sont
préférables. Mais des images de 300 Mo, je ne sais pas si c'est très
intelligent de les stocker dans une base de données ...
On supposait ici que les images sont de tailles "raisonnables". Passé 1 Mo
par image il faut certainement réfléchir au stockage (pas sûr que dans le
SGBD ça soit la meilleure solution).

--

///\3rL1n____




Merlin
Le #12267631
> La taille raisonnable maximum se situe entre 1 et 64k (la taille habituelle
des buffer pour streams). Au delà, les streams sont tout le temps
préférables.


Je parlais du principe de stockage en sgbd, pas des streams qui,
effectivement sont préférables dans tous les cas (sauf tres petites
tailles).

Le stockage d'image en base de données ne pose aucun problème dans l'absolu,
si on le couple avec un cache sur disque.



Dans l'absolu pas de pb, comme je le disais les sgbd sont depuis
longtemps conçus pour stocker des blobs. Toutefois a partir d'une
certaine taille on pourrait s'interroger. Je disais 300 Mo comme ça
parce que ce chiffre a été mentionné dans le thread. Si on doit stocker
de l'imagerie médicale qui pèse des centaines de Mo par image par
exemple, on pourrait se dire que le stockage en sgbd perd son intérêt
et risquerait de "tirer" un peu trop sur le serveur, là où un stockage
direct sur disque serait, par force, plus rapide et plus efficace.
Tout est une question de bon sens comme d'habitude.

--

///\3rL1n____
Publicité
Poster une réponse
Anonyme