image dans sql server 2005

Question

salt tout le monde;je developpe sur visual studio 2005 avec une bd sqlserver 2005;je veux inserer des phtotos dans la bd et pouvoir les afficher dans une picturebox mais sans succès;je vous pris donc de m'aider.Merci.

Bul3 · Answer

Bonjour,

une base de données n'est pas faite pour
stocker des images ! c'est une erreur
de conception totale qui risque de vous
coûter très cher à tous point de vue.
si j'étais vous, je reverrais ma copie.

Cordialement	[mon Site]	[M'écrire]	Bul

Bacterius · Answer

je vous pris donc de m'aider
Je suis le seul à prendre ça comme un subtil mélange d'exigence et de mépris ? 

Cordialement, Bacterius !

cs_cantador · Answer

[i]une base de données n'est pas faite pour 
stocker des images !/i

tout dépend en fait de la taille des images..

cantador

nivsql · Answer

En fait non, les bases de données moderne possede des type LOB (en tout cas celles que je connais) permetant justement les stockage de ce type d'objet (et dans une certaine mesure la recherche dans ce type d'objet. Il est par exemple possible en ORACLE de stocker dans un BLOB -Binary Large OBject- une image et de chercher via les packages mis a disposition des formes ou des couleurs sur ces images, ce n'est qu'un exemple). 

Toutefois ce genre de manipulation sort du contexte pur de mes connaissances je l'avous, surtout en SQL 2005. J'invite donc le demandeur a se documenter via l'aide en ligne de SQL Server 2005 (disponible a l'installation du client Management Studio ou sur les MSDN) pour trouver l'aide adéquate sur ce type d'objet.

nhervagault · Answer

salut

Regardes cet article lien

cs_cantador · Answer

@nivsql:
oui certains types BLOB Permettent le stockage des images lorque justement elles sont de taille importante.
on peut aussi y stocker du texte, des sons et même des vidéos.

cantador

cs_cidre · Answer

Une autre solution est d'encoder/décoder tes images en Base64:

Base64Decoder

Ensuite, tu peux stocké ça dans un champ NVarChar(Max).

@+

kohntark · Answer

Salut,

Je suis de l'avis de Bacterius, sans compter que "visual studio" n'a rien à faire dans le bar.

tout dépend en fait de la taille des images..
... et sans doute de l'utilisation que l'on veut en faire, à vrai dire je n'y vois que peu d'intérêt (mais il y en a)
chercher via les packages mis a disposition des formes ou des couleurs sur ces images
J'vais m'coucher moins con ce soir 
... mais est ce le but d'un SGDB ? et les performances ? la flexibilité ? ... il y aurait à dire là dessus.

Cordialement,

Kohntark -

cs_cantador · Answer

mais est ce le but d'un SGDB ? et les performances ? la flexibilité ? ... il y aurait à dire là dessus.

Dans un stockage d'images, la performance devient un aspect secondaire, seule compte la conservation des données.

ex: un musée qui conserve ses 300 000 images de tableaux de peintres célèbres.

quelle est la technique de stockage ?
(encodage, compression, cryptage etc.)

cantador

kohntark · Answer

quelle est la technique de stockage ? 
Je serais tenté de dire "disque dur", "bandes", "duplication des supports, des localisations", ... mais certainement pas SGDB, cela n'a aucun sens à mon humble petit avis : infrastructure matérielle et logicielle lourde, coût, gestion, etc ... dans le cas de la "conservation des données" bien sur.

la performance devient un aspect secondaire
Je pense au contraire que le recours à un SGDB ne se justifie que par ses performances et rien d'autre (à part peut être l'aspect sécuritaire auquel il peut répondre dans certains cas) :
Une recherche du mot 'tartanpion' dans un fichier de 2Mo => non, utilisation d'une DB
Une recherche du mot 'tartanpion' dans une phrase de 100 char => langage de prog

Une fois de plus tout dépend de l'utilisation et du but à atteindre.


Cordialement,

Kohntark -

cs_cantador · Answer

[i]Une recherche du mot 'tartanpion' dans un fichier de 2Mo => non, utilisation d'une DB 
Une recherche du mot 'tartanpion' dans une phrase de 100 char => langage de prog /i

Effectivement, tout dépend de l'objectif à atteindre selon que l'information est organisée ou pas.

Dans l'exemple du musée, on pourrait imaginer facilement un classement par pays, auteur, style année, estimation etc etc..

c'est toute la différence entre une banque de données où l'on colle tout en vrac sur un disque dur et une base de données sériée, triée, organisée et relationnelle.

et dans cette optique, ce qui compte c'est de retrouver l'information dans un certain ordre.

La performance devient nécessaire lorqu'il y a manifestement un besoin impérieux d'obtenir l'information dans un temps très court :

exemple phare: la bourse

cantador

nhervagault · Answer

Une des best pratiqies les importantes est de mettre les images dans une table a part avec une relation 1 - 1
pour éviter le chargement de l'image dans le cas de select * 

(si il y a des requetes faites à la main ;-)

kohntark · Answer

c'est toute la différence entre une banque de données où l'on colle tout en vrac sur un disque dur et une base de données sériée, triée, organisée et relationnelle. 
Nous sommes bien d'accord, mais je ne vois toujours pas l'avantage que pourrait avoir la mise en DB des photos face à l'indexation des seuls chemins vers celles ci et des données associées (pays, auteur, style, ...)
J'ai une application qui contient plus de 1010000 photos qui sont indexées en DB par leurs chemins sur la machine.
Quels bénéfices aurai je à les stocker en DB ?
A mon avis aucun, je serai obligé de mettre en place un arsenal de serveurs et d'abandonner mySQL (la base pèse déjà 4 Go), ce qui représenterait un coût financier important.

Bref, je crois que la solution "stockage des images sur disque / indexation DB" reste la meilleure.


Cordialement,


Kohntark -

cs_cantador · Answer

Quels bénéfices aurai je à les stocker en DB ? 

comme tu l'as indiqué tout dépend des besoins..
ex:
si tu veux retrouver des photos prises tel jour, tel lieu, à telle heure, avec tel appareil dans telles conditions météos et que tu souhaites que cette information soit en réseau et partagée..

alors le choix se restreint..

cantador

nivsql · Answer

De fait, si tu n'utilise les images (ou autres sons, vidéo, etc) qu'a des fins d'illustration et rien d'autre un simple lien vers un emplacement disque suffit et il serait idiot d'aller stocker ca en base (taille, difficulté d'administration, etc) et c'est le cas pour de nombreuses applications. 

Mais tu peux aussi avoir besoin de considérer tes images commes des données a part entieres dans certaines situation spécifiques (au hasard, météo ou la donnée de base est l'image satéllitaires) dans lesquelles la recherche sur ces données est importante. Aujourd'hui les SGBD modernes n'en sont qu'aux balbutiements de ces technologie (ils ont commencer avec les données textes et ce qu'on appel la recherche plein texte, l'image et le son arrivent a grand pas et a grand frais chez les gros éditeurs comme Oracle). Dans ces situations le stockage en base prend tout son sens. 

Je vous rejoins donc sur la nécéssité d'exprimer correctement le besoin avant de se lancer dans la mise en oeuvre de telles solutions, c'est toutefois possible techniquement et peut se reveler tres pratique.

Bul3 · Answer

>>...si tu n'utilise les images qu'a des fins d'illustration 
>>et rien d'autre un simple lien vers un emplacement 
>>disque suffit...
nivsql++
>>...tes images comme des données à part entières 
>>dans certaines situations spécifiques ...
>>...stockage en base prend tout son sens. 
nivsql++ ( mais peut prendre au lieu de prend )

et il me semblait évident qu'on était dans le cas n° 1

Image dans sql server 2005

16 réponses

Votre réponse

Discussions similaires