Enregistrer une image dans une base de données : BinaryFormatter vs ImageConverter
8 réponses
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
?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christophe Lauer [MS]
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.
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.
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
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# :
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# :
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# :
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/
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# :
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/
"Merlin" <Merlin@LesFees.Net> a écrit dans le message de news:
mn.450c7d637526a72c.18651@LesFees.Net...
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# :
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/
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# :
> 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____
> 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).
> 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
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" a écrit dans le message de news: %
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
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" <gilles.tourreau@pos.fr> a écrit dans le message de news:
%23EyZh2sQGHA.3460@TK2MSFTNGP15.phx.gbl...
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 ?
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" a écrit dans le message de news: %
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
> 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____
> 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.
> 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]
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" a écrit dans le message de news:
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____
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" <Merlin@LesFees.Net> a écrit dans le message de news:
mn.4b5b7d639b917186.18651@LesFees.Net...
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).
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" a écrit dans le message de news:
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
> 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____
> 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.
> 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.
