Problem beim Bilderupload in SQL Tabelle

[godlike]

Habe gerade ein seltsames Problem mit einer Tabelle in die ich Bilder laden möchte. Die Tabelle sieht folgendermaßen aus:

Wenn ich dann Bilder hoch lade klappt das auch:

INSERT INTO `******`.`*****_images` (`id`, `cp_id`, `pic_no`, `imgdata`, `imgdata_thumb`, `imgtype`) VALUES (NULL, '2274', '1', UNHEX(0xffd8ffe000104a46494600010200006400640000ffec00114475636b79000100040000003c000[....]

Doch es kommt irgendwie nichts an

Wiederhole ich den Schritt dann aber, also bei dem Datensatz den er ja angelegt hat auf "bearbeiten", Bilder auswählen und noch mal hoch laden, sind die Bilder auf ein mal in der DB und auch verfügbar.

Was könnte da den los sein?

 

[tool]

unhex erwartet einen String als Parameter, d.h. der entsprechende Part sollte bei deiner Abfrage so aussehen:

VALUES (NULL, '2274', '1', UNHEX('ffd8ffe000104a46494600010200006400640000ffec00114475636b79000100040000003c000[....]

 

[godlike]

Oha, ok Was hab ich denn dann falsch gemacht? Ich wähle die Datei ja (noch) über phpMyAdmin und "durchsuchen..."

 

[tool]

Edit: Etwas ausführlicher...

unhex erwartet als Eingabe einen String, was du lieferst ist (erst einmal) eine Zahl. Ich bin mir nicht sicher, an welchen Stellen MySQL automatisch castet und an welchen nicht, aber hier scheint das Ergebnis von unhex null zu sein, weswegen ich zunächst probieren würde, wirklich einen String zu nutzen, d.h. der Aufruf von unhex sollte etwa so aussehen:

unhex('ffaa...')

Ich habe das kurz selbst getestet:
insert into bla (fa) values (unhex(0x41)), (unhex('41'))

Ausgabe:
select hex(fa) from bla
0A
41

Irgendwas stimmt also mit der Typkonvertierung nicht, wenn man jedoch unhex('...') nutzt, wird alles korrekt eingetragen.

 

[eraser]

Ich rate davon ab Bilder in der Datenbank zu speichern, auch wenn das nicht die Frage war. Es ist wesentlich langsamer, der Browser hat Schmerzen beim Zwischenspeichern der Daten und Backups werden auch erschwert.

 

[alter_Bekannter]

Warum werden Backups erschwert, werden die dadurch nicht eher schneller weil sie in der Datenbank eine Große Datei statt vieler kleiner sind?

 

[eraser]

Wegen der inkrementellen Datensicherung, die nicht ohne weiteres möglich ist.

 

[alter_Bekannter]

Das klingt jetzt für mich noch seltsamer, gerade Änderungen kann man doch da viel leichter feststellen, halt nicht mehr auf Filesystemebene...

Gerade in godlikes Beispielstruktur mit ID's weiss man doch da genau wo man dran ist.
Übersehe ich da irgendein massives Skalierungsproblem von SQL oder bist du nur etwas zu sehr auf eine spezielle Methode der Datensicherung fixiert?

Ich muss zugeben das meine Erfahrungen mit Datenbanken Jenseits der 8 stelligen Eintragszahlen quasi nicht vorhanden sind aber bis dahin sind alle selects mit weniger als einer 6 stelligen Ergebniszahl noch sehr schnell.

 

[godlike]

Gibt es denn eine adäquate Lösung bei der ich die Bilder automatisiert als File auf dem Webspace ablege? Ich meine was ist mit Änderungen? Wenn ich jetzt Datensätze lösche oder neue hinzufüge (gibt noch nicht für alles ein Backend) muss ich die Bilder ja manuell benennen und hochladen. Automatisiert geht das ja wieder nur per Backend...

Nachtrag @tool:

Ich verstehe schon was du mir sagen möchtest hab aber Schwierigkeiten in der Anwendung. Ich lade wie gesagt ja "normal" über phpMyAdmin hoch, da kann ich ja nur auswählen und hochladen:

Ich hab hier ja also keinen Query den ich beeinflussen kann sondern nur die im Bild sichtbaren Optionen. Vielleicht muss ich mich da einfach noch mehr einlesen in die Materie...

edit: Ok, einfach das Häkchen bei "Null" entfernen und es klappt

 

[tool]

Ah, okay, ich habe dein Problem wohl missverstanden, ich dachte, du hast die Query selbst geschrieben. Freut mich aber, dass es nun funktioniert!

Zu dem Punkt "Bilder gehören nicht in die Datenbank":
Dem würde ich mich anschließen. Zu den bisher genanten Punkten kommt noch, dass der Datenbankserver ggf. nicht derselbe ist, auf dem auch dein Webspace gehostet wird und Bilder demnach erst einmal vom Datenbankserver zum Webspace geladen werden (da dort ja ein Script ausgeführt wird, dass die Datenbankabfrage ausführt) und erst danach an den Besucher der Seite geliefert wird. Bedeutet: Höhere Latenz, größerer Bandbreitenverbrauch und ggf. wird eine Beschränkung für die Größe der Datenbank schneller erreicht, falls vorhanden.

Zur eleganten Lösung, wie man die Bilder automatisch auf den Webspace legen kann: Auf diesem sollte es ein Upload-Script geben, bei dem du die relevanten Felder eintragen kannst. Das Script empfängt eine Datei vorerst an einem temporären Ort, von dort kannst du sie aber an jeden beliebigen Ort auf dem Webspace kopieren und beliebig benennen (durchnummerieren, Hashes, o.Ä. um Kollisionen zu vermeiden). In der Datenbank wird im entsprechenden Eintrag nur ein Verweis auf die Datei hinterlegt, also bspw. der Dateiname.

Ich muss allerdings zugeben, dass ich die Rahmenbedingungen nicht genau kenne, unter denen du Datenbank und Webspace betreibst und ob davon etwas öffentlich ist oder nur privat,... Was ich beschrieben habe, wäre das Standardvorgehen für normale Homepages, die etwas wie Content-Pflege ermöglichen sollen (denn diese sollte eigentlich nicht über phpMyAdmin stattfinden).

 

[eraser]

Naja, was bedeutet adäquate Lösung? Alles muss halt erstmal programmiert werden, wenn man es automatisiert möchte. Als einfachste Lösung fällt mir halt sowas wie eine API bei einem Bilderhoster ein (https://www.picflash.org/api.php). Da hast du direkt den Löschlink etc. mit dabei.

Nachtrag: Benutzt du nicht eh eine Blogsoftware? Da müsste es doch passende fertige Addons geben.

 

[godlike]

Zu den Rahmenbedingungen. Ich "pflege" hier eine Seite die über noch kein richtiges Backend verfügt. Dabei geht es um ca 10k Datensaätze von denen ~ 300 Bilder enthalten. Da es noch kein Backend gibt, einfach weil mir dazu die Zeit fehlt, lade ich eben ab und an Bilder manuell auf den Webspace (es ändert sich hier nicht viel, betrifft im Jahr ca. 20 Bilder). Das geht noch wesentlich schneller als hier jetzt irgendwelche Uploadfunktionen usw. zu schreiben. Dachte halt ich teste das mal mit ner kleinen DB aber Ok, dann komme ich wohl nicht um ein Backend, zumindest in dem Punkt, drum herum...

Und ja, DB und Webspace sind auf dem selben Server.

Nachtrag: Benutzt du nicht eh eine Blogsoftware? Da müsste es doch passende fertige Addons geben.

Nein, es handelt sich hier um eine von mir geschriebene Seite. Ich hatte nur die Datensätze und eine ziemlich veraltete Vorgängerseite als Basis. Daraus hab ich die Momentane Seite entwickelt. Somit gibt es da keine Addons leider.

Will hier auch keine fremden APIs usw. nutzen da es sich um Kundenspezifische Daten handelt und es auch um relativ viel Geld geht (die zahlen bis zu 2000€ um Bilder angezeigt zu bekommen)

Ok, dann mach ich mir mal um ein Backend Gedanken

Danke