Bonjour,
 
J'utilise PHP avec MySQL sous W2k avec le serveur Apache.
Quand j'essaye d'afficher une image enregistrée dans un BLOB, j'obtient le code de l'image plutôt que l'image elle même.
Je n'ai pas de code à proposer puisque j'ai fait l'essai avec DreamWeaverMX. Dans les FAQ DreamweaverMX, il est dit que celui-ci ne supporte pas l'affichage des images à partir d'un BLOB (ils préconisent d'enregistrer le nom du fichier dans la base et mettre l'image en dehors, à quoi sert la base alors?).
 
Pouvez-vous me conseiller (bout de code, autre,...)?

Tu l'affiches comment l'image ? Il manque peut-être juste un content-type
header('content-type: image/jpeg');
ou un truc du genre

Ben la base te sert à gérer tes références aux images...
 
Et le fait de stocker tes images à l'extérieur est effectivement une meilleure chose (à mon goût) : ça te boufferait de la place inutilement dans ta BDD, plus de soucis en cas de migration, etc.
 
[mode exemple à la con ON]
Si tu fais un annuaire de sites, tu gères les liens vers les sites, tu stockes pas les sites dans ta base, et pourtant tu as bien besoin d'une BDD.
[mode exemple à la con OFF]
 
C'est en gros le même principe pour les images.

+1 ....
y'a rien de plus con que de stocker des images dans une bdd ....
tu te rends compte de la taille qu'elle pourrait avoir rapidement    
je conseille aussi le stockage dans un repp approprié + reference dans la base  

Je pense au contraire que la base doit stocker les images (le meilleur exemple est ce forum). D'un point de vue manipulation/automatisation cette solution est excellente.
 
Concernant header('content-type: image/jpeg'); il me semble que j'avais déjà essayé, je vais vérifier.
 

 
  .... c'est ca ouais .....  
les images doivent être stockées dans la base ....  
et les messages en fichier texte...

Bon, à part rigoler, qui peut répondre à ce problème ?

bah revérifie déjà ton header, si ça affiche le contenu de l'image au lieu d'afficher l'image je vois pas trop ce que ça pourrait être d'autre
 
Et t'as toujours pas dit comment t'affichais l'image

Ok, je te réponds ce soir ou demain.

En attendant, pour répondre au petit rigolo (simogeo), voici un lien utile concernant l'implémentation de BLOB dans une DB:
http://www.microsoft.com/technet/t [...] /c1161.asp
La page explique, entre-autre, qu'un lien est créé (dans la DB) à la place du BLOB si celui-ci est trop grand (Je suppose que MySQL procède à peut près de même). Avoir une DB de 10GB avec image n'est pas forcément plus mauvais qu'en avoir une de 10Mb sans image mais avec liens (bonjour la maintenance des liens).
Je pense que cela doit se discuter au cas par cas mais ce qui est effectivement sûr, c'est qu'un champ de longueur fixe sera plus rapide qu'un autre de taille variable.

 
C'est toi le rigolo. Et ce n'est aucunement parce que tu defends le fait de mettre des images dans la BDD ce qui peut se defendre (meme si moi je le ferais pas), mais parce que tu parles sans savoir en disant :

Autant pour moi,
Je pensais de bonne foi que pour 10Ko max d'image par utilisateur (genre smileys et autres brols) cela valait la peine de les intégrer dans la DB.
A priori, moi, je l'aurais fait.

 
Encore une fois, je ne dis pas que c'est forcement une mauvaise solution, je dis juste que je ne le ferais pas et qu'apparemment, bcp ici pensent la meme chose que moi.
Il me semble plus intelligent de faire un rep. pour les images et un bout de script qui fait un dir sur le rep pour mettre a jour les liens dans la BDD (dans le cas de smileys proposes pour un forum par exemple).

cai moi
 
 

http://www.mysql.com/doc/fr/BLOB.html ... voilà pour ce qui est de la doc MySQL ....
(quand je fais du PHP, je ne me sers pas de la doc VB   )
tu remarqueras qu'il ne parle pas de la création automatique de lien lors de l'explosion dudit-champ...
 
 

stocker un lien vers un dossier dans un varchar(255) -maximum    et stocker des images ne revient pas vraiment au même... Sachant qu'on peut le faire autrement moi j'appelle ca de la surcharge ....
un serveur SQL sollicité c'est un serveur qui peut être amener un ramer....  
 
pour ce qui est de la maintenance des liens .... ca dépend de ton code .... moi je l'ai déjà mis en place .. ca tourne sans problème et j'ai pas de difficulté a le maintenir.    
 
 

dans quel ca tu as un champs fixe ? en type BLOB ?    
 
ps: tu fais ce que tu veux... moi j'en ai rien a foutre de ton appli ..... une dernière mise en garde toutefois si tu as fait le choix definitif du stockage en bdd et que tu es sur un serveur mutualisé ... saches que certains imposent des limites à la taille de la bdd  

-----------------
http://www.mysql.com/doc/fr/BLOB.html ... voilà pour ce qui est de la doc MySQL ....
(quand je fais du PHP, je ne me sers pas de la doc VB   )  
-----------------
Allons, faut pas être de mauvaise foi, on s'en fout du VB, sur ce lien, il y a un diagramme expliquant la structure de stockage d'un BLOB dans leur DB.
 
 
-----------------
stocker un lien vers un dossier dans un varchar(255) -maximum    et stocker des images ne revient pas vraiment au même...  
-----------------
Evidemment.
 
 
-----------------
un serveur SQL sollicité c'est un serveur qui peut être amener un ramer....
-----------------
C'est vrai dans les deux cas (avec et sans images)
 
 
-----------------
pour ce qui est de la maintenance des liens .... ca dépend de ton code .... moi je l'ai déjà mis en place .. ca tourne sans problème et j'ai pas de difficulté a le maintenir.    
-----------------
Bien sûr... on ne compte plus les pages où, à la place de voir apparaître une image, on ne reçoit qu'un petit icône misérable nous informant qu'effectivement, on aurait dû en avoir une :-)
 
 
------------------
dans quel ca tu as un champs fixe ? en type BLOB ?    
------------------
varchar(255), non ?
 
 
------------------
ps: tu fais ce que tu veux... moi j'en ai rien a foutre de ton appli .....  
------------------
Voilà bien le langage qu'on ne trouve pas (ou peu) dans les forums anglo-saxon.
 
 
------------------
une dernière mise en garde toutefois si tu as fait le choix definitif du stockage en bdd et que tu es sur un serveur mutualisé ... saches que certains imposent des limites à la taille de la bdd  
------------------
Je n'ai fait aucun choix, je suis venu dans ce forum poser une simple question. Tu m'as ri au nez, merci mais c'est pas ce que j'attendais (même si j'ai fais une erreur d'appréciation sur le stockage d'image).

je t'ai d'abord donné mon avis sur la question  .
tu essayes de me démontrer le contraire avec un contre-exemple.... .... bien évidemment je rigole.    (toutefois sans mechanceté). Et tu reviens sur le topik en m'appelant le petit rigolo et avec des arguments qui ne sont toujours pas très convaincants à mon sens.
 
Le langage 'non-anglo-saxon compliant' n'est pas insulte.... envers toi ... c'est en guise d'une sincerité dans mes propos.
 
ps : si je peux t'aider je le ferais encore    
 
 
pour reprendre tes propos :
 

oui mais MySQl ne fonctionne pas de la même façon.
 

dans les 2 cas ils sont sollicités mais on ne lui demande pas le même effort
 

il est tiré par les cheveux cet argument quand même ... limite mauvaise foi    
 

oui ..... il est possible de stocker le lien dans un varchar(30) aussi pour gagner encore quelques octets

Ok, j'ai résolu mon pb. C'était effectivement un problème de header. En fait Dreamweaver m'a causé + de soucis qu'il en a résolu. Le problème avec ces softs, c'est qu'on ne maîtrise pas le code.
Merci et à bientôt,

Veux faire le malin en essayant de nous faire comprendre que stocker une image dans la BDD caiplusmieu et il code avec DW...

Je suis désolé, les "petits rigolos" () ne m'ont pas encore convaincu...
Vous dites "ça alourdi la base". Et alors ? Que l'image soit dans un répertoire ou dans la base, ça bouffe de l'espace pareillement ! Et ça m'étonnerait grandement que la vitesse d'exécution en pâtisse bc...
Je trouve ça vraiment "sale" de stoker un lien vers un fichier qui n'a aucun rapport. Je fais comme ça depuis longuement et ça m'a toujours dérangé.
 
A vous...

Excusez moi j'ai suivi le topic car le sujet m'intéresse mais je n'ai pas encore lu d'arguments qui expliquent pourquoi ce n'est pas bien de stocker de gros objets dans labase. La question m'intéresse c'est pour cela que je relance.  
 

Pour reprendre l'exemple d'un serveur mutualisé (ou par exemple t'as 20Mo de données MySQL et 50Mo de données pour les fichiers) tu vois tout de suite qu'il vaut mieux stoquer les images hors de la base et garder la base pour les données variables (par exemple les messages d'un forum).
 
D'autre part, quand on dit que ca alourdit la base : si à chaque appel d'un smiley tu dois aller faire une lecture de la base, générer l'image puis la transmettre, ton serveur il souffre. Alors que si tu stoques l'image en tant qu'image dans un repertoire, le serveur n'a plus que la partie envoi du fichier à faire

Plusieurs choses :  
 
- Pourquoi veux tu stocker des images dans une BDD (des images générées en PHP, a la limite mais sinon .... je vois pas trop l'intéret), et puis ca doit etre chiant a mettre en place une BDD comme ca. Comme on te l'a dit, stocke plutot le nom des images (ca reviendra a peu pres au meme)
 
- N'utilise pas Dreamweaver MX pour tout ce qui est PHP-SQL.
DW, c'est bon pour créer des pages Web en HTML pour les débutants qui veulent faire des trucs jolis (et encore des fois, faut reprendre le code) mais pour le php-SQL, rien ne vaut un bon viel éditeur de texte (Jedit, UltraEdit ...)
Ou alors tu créé ton interface sous DW puis l'édite après.

Effectivement, pour un smilley c'est plutôt stupide. Mais par exemple, tu publies un article avec des images pour l'illustrer. Il te faut deux tables ("articles" et "images" ) reliées par leurs ID. Je trouve infiniment plus propre que l'image soit stoquer dans la table images, plutôt que stoquée dans un répertoire qui n'a rien à voir et qui, de plus, est commun à toutes les images stoquées dans la table. C'est juste une question de cohérence...
 
Et question performance, je ne suis pas sur que ce soit dramatique d'afficher une image stoquée dans la base, plutôt que d'extraire son nom et de l'afficher ensuite.

Tu peux très bien faire un repertoire pour chaque article et comme ça tu gardes toutes les images de l'article ensemble te séparément des autres.  
 

Ca serait à essayer ... je pense le contraire de toi mais bon S'il y a 10 visiteurs en même temps qui consultent des articles, ta base va devoir sortir 10*10ko pour les images au lieu de 10*5 octets pour les adresses et là ça va faire mal.

 
monnoliv : Pourrai t'on savoir s'il te plait, tout le monde émet des hypothèses sur l'utilisation d'une telle pratique, mais pour toi c'est quoi ?
Up  

Certes, mais tu as bien compris ce que je veux dire. Un répertoire, quel qu'il soit (même avec l'ID de l'article en nom) n'est relié en rien à une table dans une bdd.
Enfin bon, je défends un système qui je n'utilise pas moi-même mais que je trouve tout de même très cohérent.
 
Je coderais bien un petit exemple pour tester les performances, mais là je suis sur un portable avec Windows XP et je suis un peux perdu sans mes outils Unix.

 
Je comprends pas trop le problème que l'image ne soit pas directement reliée à la base Si le site est bien fait ca devrait pas géner  
 
N'empèche, ce système peut etre intéressant dans le cas d'un serveur dédié où on a pas de limitation dans la taille de la base de données (sinon c'est pas viable).

Exemple d'incohérence : lorsque tu affiches une image que tu ne connais que pas son ID. Comment tu fais pour l'afficher si elle n'est pas dans la table ?
Tu crées une page PHP  (adresse : chezmoi.com/img.php?id=7) renvoyant du code HTML avec un tag img.
 
Alors que si l'image est stoquer dans la base, tu l'affiches direct.
 
A un moment j'avais essayer d'afficher l'image d'après l'adresse avec un fopen, c'était déja moins incohérent (du coté client).
 
J'ai fait un petit code trés simpliste, si quelqu'un pouvait tester les performances :
insert_img.php

 
img_sql.php

 
img.php

Perso je nomme simplement le nom de l'image selon l'ID de la bdd. Je vois pas ou est le problème.
 
Mais à mon avis, mettre les images dans la base est une très mauvaise idée.

Un exemple simple :
une base de donnée avec des images de 600 ko stockés dedans
une serveur web avec php qui utilise cette base de donnée.
t'as une personne qui a besoin d'une image : le navigateur envoie la demande au serveur, le serveur envoie la demande au serveur sql et il doit attendre la réponse.
avec un réseau à 10Mb, il faut 0.5 secondes par images. Si le navigateurs a besoin d'une disaines d'images, ca méttra 5 secondes pour revenir (en considérant que toutes les images sont demandé au même moment).
Avec 6 personnes qui ont besoin des mêmes images en même temps on tombe à trente secondes pour que tout soit envoyé au navigateur.
 
Une personne de plus et on tombes a trente seconde d'exécution (ou plustôt d'attente d'infos) et 10 images qui seront jamais envoyé (time out du script php).
 
Là, on en est à 70 images demandés à la fois et on a déjà des problèmes. Je te laisses imaginer ce que ca va donner quand la demande sera plus forte.
 
Evidemment, pour un tout petit site ca posera pas de problème, mais pour un site comme hardware.fr je penses que les premiers jours après la publication d'un article, ca serait l'horreur pour accéder aux images avec un tel système.

 
Toi c'est ca qui se passe :
client web>serveur web>bdd>serveur web>client web
 
mais avec un lien dans la base il faudra :
client web>serveur web>bdd>serveur web avec accès disque pour récupérer les images>client web.
 
Avec un temps d'accès disque pour chacune des images. Donc je vois pas encore une différence flagrante.

fais des tests à mon avis c'est assez flagrant.

Ben théoriquement un accès à la bdd est plus rapide qu'un accès disque donc le problème doit être autre part.

 
 
ça dépend de la montée en charge. Ce sujet est stérile. Personne ne sait pkoi apparement   , mais tout le monde, ou presque, est du même avis...
 
 
http://dev.nexen.net/news/gen.php3 [...] 1,0,0.html
A notter qu'il est plutot conseillé de ne stocker en base que le chemin vers l'image et de stocker celle-ci "normalement" sur le serveur.
 
 
http://www.phpindex.com/articles/a [...] lement=208
Le stockage des images d'un site web dynamique pose souvent problème. Faut-il enregistrer l'image dans la base de données ou bien simplement le chemin vers le fichier ?
 
Jérôme Morlon nous présente le problème et donne en quelques lignes de code les deux solutions. Quoi qu'il arrive, stocker l'image dans la base MySQL nécessite beaucoup, beaucoup plus de ressources et peut-être aussi plus d'espace disque. J. Morlon nous parle aussi de la possibilité de faire des recherches dans la base de données sur "des formes au sein des images". J'aimerai beaucoup avoir plus d'information là dessus.  
 
Il y a par contre un gros intérêt avec les images stockées sur le disque dans l'arborescence web, en plus du gain de rapidité, c'est la possibilité d'utiliser la mémoire cache de votre navigateur. Il n'est pas prouvé que les navigateurs ne rechargent pas les images déjà chargées qui sont stockées en base de données. Ce serait une surcharge supplémentaire pour la première solution.
 
Attention, cet article s'adresse plutôt aux débutants.

et la bdd,elle est ou?sur un disc dur non?  

J'ai peur de mal comprendre... Tu nous parles de problèmes de bande passante ?!!    
C'est sûr que lorsque tu as une base de donnée reliée au serveur par un réseau 10 Mb c'est une solution à éviter !!!
 
Sinon, je viens de vérifier IE et Mozilla savent mettre en cache les images provenant d'un bdd (je ne vois pas pourquoi ils ne le pourraient pas...).
 
Mais bon, je répète que je suis séduit par ce système uniquement pour des raisons de cohérence, je veux bien croire qu'il est moins rapide. Et puis, y pas que les sites web dans la vie d'une bdd.

Comme tu veux. Au moins tu es au courant  

Si je me plante, ça sera vot' faute.  
 

Et la base de donne, elle stocke continuellement toutes les images dans la mémoire vive de l'ordi au détriment des autres infos de la base?
A mon avis, dans les deux cas, il y a autant d'accés disque. (les serveur web aussi conservent un certain nombre d'info en mémoire vive pour gain de temps.)