Version imprimable
Bonjour j'appreçis comment ce fait les quetions et reponse sur ce forum;
Moi j'ai un probleme d'enregistrement d'image dans une base de donnée.
je programe en delphi mysql.
j'ai defini le champ blob dans la base, mais je n'arrive pas à soumettre une image de plus de 500 ko à 1000 ko.
mytable c'est le compasant de mydac de mysqlCode:Mytable.(FieldByName('Photo') as TBlobField).LoadFromFile(OpenDialog.Filename, ftBlob);
photo c'est le nom du champs image dans la base mysql.
Aider moi.
vérifie le type de BLOB (65Ko), si MEDIUM (16Mo) ou LONG (2Go)
Modifie dans le fichier My.ini la taille d'une requête genre max_allowed_packet
Il me semble que c'est suffisant !
Perso, j'ai eu ce problème sur des fichiers PDF même compressé en Zip Level 9 qui pouvait dépasser 1 Mo (valeur par défaut sur le server)
Sache qu'en MySQL, tu peux faire un UPDATE ou INSERT d'un champ Blob en mettant le Binaire en Base64 ce qui permet de l'utiliser comme une chaine, et cet encodage n'est pas altéré par l'UTF-8
J'ai utilisé MyDAC (Devart Core Lab) pendant plus de 4 ans, c'est un très bon choix !
Merci,
Comme je l avais dit je suis un debutant alors vous aleer beaucoup m excuser de mes erreur et j epere qu avec le temps je m habituerai. j ai essyer mais je ne trouve pas max_allowed_packet dans my.ini mais c est plutot dans my-large.ini et my.small.ini ou my-medium.ini, svp je fais comment?
Merci beaucoup
Comment mettre le binaire d une base en base64 pour permettre que me insertion et update n altere pas le utf8.
Merci
j'ai enfin trouvé, j'ai seulement ajouté max_allowed_packet=16M dans mon fichier my.ini et la taille des fichiers des images sont automatiquement enregistrée.
au fait dit quel est l'inconvenient en enregistrant directement des fichier images dans la base. y t il un probleme de lenteur à long therme?
Est une bonne methode?
La recherche est-elle rapide?
:ccool: Kokey :ccool:
Je te conseille d'utiliser une ou plusieurs tables de BLOB !
C'est à dire que tu sépares les BLOB des données principales !
Cela te permettra de conserver de grande perf sur les requêtes sur les données métiers, facilite la sauvegarde aussi !
Ne jamais faire de SELECT * sur une table avec des BLOB, bcp trop lent et souvent inutile !
Tout dépend aussi le volume et les technologies d'accès !
Stocker les images en BLOB à l'avantage de centraliser les données !
Certains vont te dire de stocker les chemins des images et d'avoir un serveur de fichier !
Personnellement, je suis contre le stockage des chemins complets, il faut priviliégier des chemins relatifs ou encore mieux un système de chemin qui se calcule donc sans risque de perte de lien (fréquent lorsque l'on sépare Table et Fichiers)
Tu as une table de Personne, chaque personne à un AutoInc dans la Table, il peut servir de lien !
Un répertoire calculé de la forme ".\Files\001\000001\0000000001\Photo.jpg"
0000000001 étant la valeur de l'AutoInc paddé sur 10 caractères
000001 étant les 6 digits les plus significatifs
001 étant les 3 digits les plus significatifs
Photo.jpg est la seule partie du nom de fichier stockée dans la table Personne
Dans le cas d'un réseau local, aucun soucis, un petit partage windows ou samba, le tour est joué !
Dans le cas d'une application client lourd en WAN, il faut prévoir du téléchargement de fichier (FTP, HTPP, Flux...) ce qui complique nettement les choses par rapport à un stockage direct en BLOB !
Chaque solution apporte une réponse et un problème en même temps ! :mouarf:
Je n'ai pas compris à quoi servent les 3 sous-dossiers ? Et quelle est l'utilité de "padder" à 10 caractères ou autre, si ce n'est pour le tri alphabétique dans un explorateur de fichiers ?
Mettre les images (ou autres fichiers) dans tes tables blob dédiées, hmm, intéressant... est-ce que tu as des liens qui parlent de cette technique comparativement à d'autres ?
Essaye d'ouvrir un dossier sous l'explorateur avec 1000 dossiers !
Tu verras, il adore !
Le découpage en sous dossier permet d'éviter un temps de lecture trop long lors de l'ouverture d'un dossier
le pad à 10, c'est tout simplement parce qu'en général, on utilise un INTEGER comme AutoInc, limité à 2,1 milliards, donc 10 digits maximum !
Ensuite, le Pad, permet un découpage plus facile des 6 et 3 digits significatifs !
Pour la Personne ID 512789, ça donnerait
".\Files\789\512789\0000512789\Photo.jpg"
Si tu atteinds les 2 milliards d'enregistrements, effectivement le nombre de dossier au dernier niveau atteinds les 20000 sous dossiers, mais avant d'avoir une telle base, il faut vouloir gérer le trombinoscope de tous les Chinois :mouarf: et la FAT aura surement déjà explosé ! :aie:
Pour les Blobs isolés, c'est ni plus ni moins, l'application de ce que fait Paradox avec les fichiers mmo, où l'on peut stocker de 0 à 255 caractères du blob dans la table et le reste dans le fichier mmo !
Tu peux lire aussi 14.1.3. Formats de table MyISAM et l'impact d'utiliser VARCHAR, BLOB ou TEXT
Les performances des tables à taille fixe sont imbattables !
En même temps, en MySQL, CHAR et VARCHAR sont modifiés en fonction de leur longueur CHAR de 1 à 3, VARCHAR à partir de 4, il y une option pour forcer l'utlisation CHAR à plus de 3 pour conserver ROW_FORMAT à FIXED
Salut,
j'ai un probleme, je vienx de faire une petite application, qui me permet de scanner et de stocker dans une base mysql? mais mon probleme est que les fichier stocker que j'enregistre dans ma base, sont trs lourd, à peu près 8M, mais j'ai jusqu'à 8 champ qui me stock les images dans des champs de type blob,
Y a t il une possibilité de changer le fprmat de scanage ou y at i un code qui peu me permettre de reduire la taille de mes fichiers scanner avant de le envoyer dans la base?
Aidez moi
kokey
utilise un outil de Compression comme TVCLZip vers un objet Stream que tu pourras envoyé à ta DB MySQL via une requête paramêtrée
En MySQL, tu peux écrire un BLOB via SQL en le formattant en Base64, si tu préfère un SQL !