PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Datei in MySQL-Tabelle schreiben


mf_2
2004-09-13, 02:16:29
Hallo,

ich ahb ne Datei "bild.gif", die ich in eine MySQL-Tabelle "bilder" in der DB "programm" schreiben moechte. ich havb gehoert, dass so etwas moeglich ist, hab aber gerade den Befehl ned zur Hand. Die Tabelle hat folgende Felder:

name ( typ )

id ( INT )
description ( blob )
name ( varchar50 )
file ( longblob )

Ist longblob der geeignete typ fuer eine datei? wie kann ich die datei in eine mysql-db speichern?

Danke im voraus,

mf_2

clm[k1]
2004-09-13, 10:44:37
Du müsstest die in irgend einer form serialisieren, und dann speichern...

es stellt sich natürlich die frage, ob es nicht sinnvoller wäre, die datei normal zu speichern und in die datenbank nur den namen und pfad der datei...

gruß
clm[k1]

HellHorse
2004-09-13, 10:53:53
TINYBLOB, BLOB, MEDIUMBLOB und LONGBLOB unterscheiden sich bloss in der maximalen Grösse/Länge. Bei LONGBLOB sind das 2^64 bytes, bei MEDUMBLOB 2^24 und bei BLOB nur noch 2^16. Es hängt also davon ab, wie gross deine Bilder sind, eigentlich sollte MEDIUMBLOB reichen.

Normalerweise (zumindest in JDBC) arbeitet man in Zusammenhang mit BLOBs mit byte-Arrays. Du brauchst also vermutlich den Dateiinhalt als byte-Array.
Und dann ist es halt ein ganz normales SQL-INSERT Statement

INSERT INTO name (id, name, description, file) VALUES (?, ?, ?, ?)


BTW, warum verwendest du für Description nicht Text? Kommt zwar aufs Gleiche raus, finde ich aber viel weniger hässlich. Wenn du MySQL 4.1 hast, kannst du sogar VARCHAR nehmen, wie sich das gehört.

http://dev.mysql.com/doc/mysql/en/BLOB.html
http://dev.mysql.com/doc/mysql/en/Storage_requirements.html

mf_2
2004-09-14, 00:09:02
TINYBLOB, BLOB, MEDIUMBLOB und LONGBLOB unterscheiden sich bloss in der maximalen Grösse/Länge. Bei LONGBLOB sind das 2^64 bytes, bei MEDUMBLOB 2^24 und bei BLOB nur noch 2^16. Es hängt also davon ab, wie gross deine Bilder sind, eigentlich sollte MEDIUMBLOB reichen.

Normalerweise (zumindest in JDBC) arbeitet man in Zusammenhang mit BLOBs mit byte-Arrays. Du brauchst also vermutlich den Dateiinhalt als byte-Array.
Und dann ist es halt ein ganz normales SQL-INSERT Statement

INSERT INTO name (id, name, description, file) VALUES (?, ?, ?, ?)


BTW, warum verwendest du für Description nicht Text? Kommt zwar aufs Gleiche raus, finde ich aber viel weniger hässlich. Wenn du MySQL 4.1 hast, kannst du sogar VARCHAR nehmen, wie sich das gehört.

http://dev.mysql.com/doc/mysql/en/BLOB.html
http://dev.mysql.com/doc/mysql/en/Storage_requirements.html

ich hab leider keine ahnung, was du mit einem byte-array meinst. ich hba noch nie dateien in eine db geschrieben. mit welcher php-funktion kann ich eine datei fuer die db vorbereiten und mit welcher funktion kann ich sie wieder auslesen?

winter
2004-09-14, 15:02:52
http://www.phpbuilder.com/columns/florian19991014.php3 <-- Biddasehr, vorallem die nächsten paar seiten sind für dich interessant.
Sorry, dass es ned früher gekommen is, aber du weißt ja, bei uns is jetzt die Schule losgegangen X-D

Zufall, ich hab mich einen Tag vor deinem Thread darüber informiert X-D

Birdman
2004-09-14, 18:50:36
ihhh, binary objects in einer Database speichern....was schlimmeres für die Performance gibts nicht.
Dateien gehören in einen Verzeichnisbaum und der Pfad/Dateiname in die Datenbank.

Coda
2004-09-14, 19:06:52
Warum sollte das so schlimm sein? ReiserFS ist auch ne Datenbank und nen wunderbares Dateisystem ;)

Birdman
2004-09-14, 19:13:35
Ein OS wird auch nicht versuchen, eine komplette Partition im RAM abzubilden ;)

Coda
2004-09-14, 19:39:13
Sollte eine gute Datenbank auch nicht machen.

mbee
2004-09-14, 21:40:11
ihhh, binary objects in einer Database speichern....was schlimmeres für die Performance gibts nicht.
Dateien gehören in einen Verzeichnisbaum und der Pfad/Dateiname in die Datenbank.

Dem kann man nur zustimmen. Mit BLOBS u.ä. sollte man eigentlich nur hantieren, wenn eine selbst programmierte Dateiverwaltung absolut nicht in Frage kommt.

Sphinx
2004-09-15, 03:22:57
Hallo,

ich ahb ne Datei "bild.gif", die ich in eine MySQL-Tabelle "bilder" in der DB "programm" schreiben moechte.

Danke im voraus,

mf_2

Ja es ist möglich - aber währmstens abzuraten.

Warum in eine Datenbank - Abspeichern ?

Du wirst schnell merken das es Performancemäßig bessere Wege/Lösungen existieren.

Wie Birdman schon erwähnte...

BINS gehören ins Dateisystem -> Informationen darüber (id,description,name,pfad,...,...) kann man gern in eine Datenbank schreiben...

HellHorse
2004-09-15, 09:45:01
ihhh, binary objects in einer Database speichern....was schlimmeres für die Performance gibts nicht.

Wirklich Performance, oder einfach nur RAM?

Sphinx
2004-09-15, 11:09:58
Aus MYSQL :

Bei einer normalen Webserver-Konfiguration sollten Bilder als separate Dateien gespeichert werden. Das heißt, speichern Sie nur einen Verweis zur Datei in der Datenbank. Der Hauptgrund ist, dass normale Webserver viel besser darin sind, Dateien zu cachen als Datenbankinhalte. Daher ist es viel einfacher, ein schnelles System zu bekommen, wenn Sie Dateien benutzen.

http://dev.mysql.com/doc/mysql/de/Tips.html

HellHorse
2004-09-15, 15:18:55
http://php.dreamwerx.net/forums/viewtopic.php?t=6

Birdman
2004-09-15, 18:06:59
Bis vielleicht ein paar 100MB an Daten mag die Datenbankmethode schneller sein, danach bricht die Performance aber stark bis extrem ein.

RAM ist zudem nur ein Problem...welches sich zudem bei x86 Systemen ab 2GB noch gravierender in Szene setzt.
Auch der interne Verwaltungsaufwand der Datenbank steigt extrem an, z.B. optimieren der Tabellen --> DB muss hier evtl. sinnlos Gigabyteweise BLOB Objects hin und herverschieben um die paar sinnvollen Daten am richtigen Ort zu haben --> Disk und CPU Load ohne ende.

HellHorse
2004-09-15, 18:33:22
Bis vielleicht ein paar 100MB an Daten mag die Datenbankmethode schneller sein,
Würde mich nicht wundern, wenn wir im Fall vom Threadstarter nicht mal auf 10 MB kommen.

mf_2
2004-09-16, 02:47:33
Hallo, ich bins mal wieder. Danke fuer die vielen beitraege!

ich will die bilder in einer db schreiben, da ich mit php / mysql irgendwie nicht so gern im windows-filesystem arbeite. ich weiss selber ned so genau, warum ich dem sooo abgeneigt bin.
meine serverconfig ( sollte schon n bisschen was aushalten ):
apache 2 ( xampp 1.45 )
1.2ghz athlon-c, fsb100/133
1,024 mb pc133-ram
4x 80 gb 7200rpm hdds im raid 10 modus, mit einem sil0680 medley controller im pci-bus.

mbee
2004-09-16, 08:58:50
Hallo, ich bins mal wieder. Danke fuer die vielen beitraege!

ich will die bilder in einer db schreiben, da ich mit php / mysql irgendwie nicht so gern im windows-filesystem arbeite. ich weiss selber ned so genau, warum ich dem sooo abgeneigt bin.
meine serverconfig ( sollte schon n bisschen was aushalten ):
apache 2 ( xampp 1.45 )
1.2ghz athlon-c, fsb100/133
1,024 mb pc133-ram
4x 80 gb 7200rpm hdds im raid 10 modus, mit einem sil0680 medley controller im pci-bus.


Du lässt ein AMP-System nicht auf einer *IX- sondern auf einer Windows-Plattform laufen?
In dem Fall wärst Du performancemässig sicher mit ASP.NET/SQL-Server bzw. MSDE besser bedient.
Und gerade bei einer Webanwendung hat man noch mehr gute Gründe auf BLOBS zu verzichten.

mf_2
2004-09-16, 16:25:19
Was goibt es denn noch fuer alternativen fuer blob?

mbee
2004-09-16, 16:49:55
Nur diejenige, die Dir nicht gefällt :D

Ist natürlich auch ein Grund, den man akzeptieren muss.

ch würde es halt über Pfad- und Dateiangaben machen, die auf die entsprechenden Dateien im File-System referenzieren. Natürlich hat man auf diese Weise im Fall von Lösch-Operationen bzw. auch generell (einzigartige Dateinamen während eines Uploads erzeugen, damit man nicht versehentlich Dateien überschreibt, etc.) ein wenig mehr Arbeit damit. Ich persönlich finde diese Lösung allerdings gerade für Web-Anwendungen "sauberer" als mit Binärobjekten in einer DB herumzuhantieren.

Coda
2004-09-16, 22:13:17
In dem Fall wärst Du performancemässig sicher mit ASP.NET/SQL-Server bzw. MSDE besser bedient.
Das glaube ich kaum falls er Apache 2 verwendet.

winter
2004-09-16, 22:18:39
Ich wüsste nicht, was dagegen spricht, images im KiB Bereich (nein, wir reden hier wirklich nicht von MiB) übersichtlich (!!!) in einer MySQL Datenbank zu lagern, vorallem für ein Webprojekt. Das hat beispielsweise bei Smilies oder Avataren für ein Board den Vorteil der hohen Übersichtlichkeit und der leichten Kontrollierbarkeit der Dateiengröße noch vor der festen Speicherung des Uploads. Vorallem bei wirklich großen Projekten erleichtert das die Administration ungemein. Außerdem ist bei beherzter Programmierung der Abfrageroutinen (Stichwort free_result) die Belastung für Prozessor und Arbeitsspeicher nur minimal höher. Unter Windows kommt noch hinzu, dass sich die Daten so effizienter schützen lassen.

Allerdings, bei Daten über (pimaldaumen) 200KiB ist das wirklich nutzlos. Die Daten sind dann wirklich groß genug, dass man sie ohne umwege zum nutzer schicken sollte.

Soweit meine Meinung dazu.

BTW: So lächerlich es auch anhöhren mag, die Bilder sind dann auch problemlos selber gzip-bar. Wieso man das Brauchen sollte? Bei Smilies kann GZip z.b. darüber entscheiden, ob sie in einem Packet oder in zweien übertragen werden können. Bei vielen smilies und einer trägen verbindung kann sich das durchaus spürbar auf die Ladezeit auswirken, da nur die Bestätigung für ein Packet zu senden ist, eine zweite würde doppelt so lange brauchen.

mbee
2004-09-16, 23:21:37
Das glaube ich kaum falls er Apache 2 verwendet.
An der schlechten Performance der Zend-Engine (PHP) unter Win (verglichen mit ASP.NET) ändert auch ein Apache nichts.
Bestes System in der Richtung ist und bleibt ein LAMP-System.

mf_2
2004-09-18, 00:33:44
Außerdem ist bei beherzter Programmierung der Abfrageroutinen (Stichwort free_result) die Belastung für Prozessor und Arbeitsspeicher nur minimal höher.

Was genau ist denn free_result?

winter
2004-09-18, 12:51:22
mysql_free_result( resource result );

Schmeißt die Ergebnisse von MySQL Abfragen sofort aus dem Arbeitsspeicher, und wartet nicht wie PHP normalerweise damit bis zum Ende des scriptes. Wenn das Bild also zum Client geschickt worde, steht dank free_result der Speicher sofort wieder zu Verfügung und belastet das System nicht. Wenn sich viele Leute die Seite gleichzeitig ansehen, dauert es so wesentlich länger, bis es zum *Out of Memory* kommt.