Bilder in eine SQLite DB speichern und später daraus laden?

Rhodan

Hallo zuasmmen,

kaum ein halbes Jahr um und schon muss ich wieder eine Frage loswerden

Ich arbeite zur Zeit an einer Bücherdatenbank, um mich ein wenig in SQLite einzulernen.
Was mir noch Probleme bereitet:

Ich möchte die Cover (JPGs, BMPs, etc.) der Bücher direkt in der Datenbank ablegen können und später in meiner GUI entsprechend anzeigen.
Vermutlich muss ich die Bilder binär einlesen, was ich bereits (hoffe ich) erfolgreich mit

Code

$hFile = FileOpen(GUICtrlRead($inpPfad),16)
$tmp = FileRead($hFile)

erledigt habe.
Anschließend kann ich das wohl in einer BLOB-Zelle in der SQLite-DB ablegen.

Nur...
Was mach ich jetzt, wenn ich die Rohdaten als Bild in meiner GUI angezeigt bekommen will?
Ich möchte die Bilder also direkt in der DB speichern und später von dort in meiner GUI anzeigen lassen.

Hat da jemand einen Tipp für mich?

Gruß
Rhodan

**chip**

Ja ich haben einen Tipp, die Datenbank so verwenden wie sie gedacht ist und zwar um Daten zu speichern und keine Bilder. Speicher in der DB den Bildnamen und lege die Bilder in einem Verzeichniss ab.

**autoBert**

@Rhodan: benutze einfach eimal die Suchfunktion Progandy hat mir dieses (vor Jahren) schon einmal beantwortet. Fals du es nicht findest (weil dieser Teil des Forums gecrasht hat) einfach noch einmal melden.

mfg autoBert

**BugFix**

Du kannst Mediendaten (oder auch große Textdateien) mit dem Datentyp BLOB direkt in der DB abspeichern.
Hier kannst du dir ein Bsp. dazu ansehen.

progandy

Um das Bild ohne temporäre Datei darszustellen, kannst du diese Funktionen verwenden (GDI+ wird benötigt)

http://www.autoitscript.com/forum/topic/71…391#entry873391

Rhodan

Vielen Dank Leute
Das sieht seeehr interessant aus.

chip:
Warum sollte man das deiner Meinung nach nicht tun?
Klar, die DB wird "etwas" größer, aber ich stelle mir vor, wenn ich indices für die restlichen Spalten erstelle, sollte die Größe der Bild-Dateispalte nicht so die Geschwindigkeit beeinträchtigen.
Korrigiert mich bitte, wenn ich da falsch liege. Ich fang ja erst an

Gruß
Rhodan

**chip**

Weil eine Datenbank eine Datenbank ist in ein Bildarchiv ein Bildarchiv ;).

Wäre wie wenn bei deinem Fahrrad Benzin in die reifen Füllen würdest.

Hier auch ein entter Blogeintrag zum Thema Bilder in Datenbanken: http://www.php-faq.de/q-db-blob.html. Bezieht sich zwar auf php, aber lässt sich im Datenbankteil 1:1 portieren.

**autoBert**

chip: die Vorteile die dort genannt werden sind enorm. Die Nachteile speziell die Peformance lassen sich aber nicht 1:1 auf dieses Vorhaben ansetzen, da php ja auf Web-Servern läuft und dort ja viele Bilder gleichzeitig pro Seitenaufruf geladen werden müssen. Und selbst dein verlinktes Thema komm zu folgendem:

Zitat

Fazit

Ob Bilder in einer Datenbank persistiert werden oder nicht, sollte den Umständen nach entschieden werden. Bei kleinen oder schwach frequentierten Seiten spricht nichts gegen eine solche Lösung. Sind die Anforderungen hingegen höher, muss dies bereits bei der Konzeption bedacht und sorgfältig geprüft werden.

Ergo: eine Datenbank ist eine Datenbank. Bilder sind Daten, also kann und darf man sie auch in einer Datenbank speichern. Dies hat den Vorteil dass man sie gut verwalten kann,

mfg autoBert

**chip**

Wenn das so siehst ist alles Daten, dann könntest auch ganze Setups, Filme ect. in eine sqlite prässen was an den Grundgedanken hinter einer sqlite bzw. andere DB komplett vorbei geht und jedem Design Pattern Konzept wiederspricht.

Prajoss

Moin,

das Probleme ist bei mir selbst aufgetreten vor ein paar Wochen und nach suchen und Hilfe ausm Forum
sieht mein Skript so aus:

Bild einlesen (leicht abgeändert):

Spoiler anzeigen

[autoit]

$pic = FileOpenDialog("Bild auswählen", @ScriptDir & "\Bilder", "Bilder (*.jpg;*.bmp;*.png)", 1 + 2)
If FileExists($pic) Then
$h_pic = FileOpen($pic, 16)
$v_pic = FileRead($h_pic)
EndIf

[/autoit] [autoit][/autoit] [autoit]

_SQLite_Open($h_db)
_SQLite_Exec(-1, "Insert Into " & $tabelle & " values (" & _SQLite_Encode($v_pic) & ");")
_SQLite_Close()

[/autoit] [autoit][/autoit] [autoit][/autoit]

Und um das Bild wieder zu laden:

Spoiler anzeigen

[autoit]

_SQLite_Query(-1,"SELECT Bild FROM " & $tabelle & " WHERE name='" & $name & "';", $hQuery)

[/autoit] [autoit][/autoit] [autoit]

_SQLite_FetchData($hQuery, $a_row, 1)

[/autoit] [autoit][/autoit] [autoit]

$Bild_Daten = $a_row[0]

[/autoit] [autoit][/autoit] [autoit]

_SQLite_QueryFinalize ($hQuery)

[/autoit] [autoit][/autoit] [autoit]

_SQLite_Close()

[/autoit] [autoit][/autoit] [autoit]

$Bild_pfad = _Erzeuge_Bild_Tmp($Bild_Daten)

[/autoit] [autoit][/autoit] [autoit]

If FileExists($Bild_pfad) Then

[/autoit] [autoit][/autoit] [autoit]

_GDIPlus_Startup()
Local $hImage = _GDIPlus_ImageLoadFromFile($Bild_pfad)
Local $iX = _GDIPlus_ImageGetWidth($hImage)
Local $iY = _GDIPlus_ImageGetHeight($hImage)
_GDIPlus_ImageDispose($hImage)
_GDIPlus_Shutdown()
EndIf

[/autoit] [autoit][/autoit] [autoit]

$bild = GUICtrlCreatePic($Bild_pfad, 370, 70, $iX, $iY)

[/autoit]

Hier die Funktion um Temporär das Bild auszulagern:

Spoiler anzeigen

[autoit]

Func _Erzeuge_Bild_Tmp($sHex)
Local $sFile = @TempDir & "\sqldbtmp.jpg"
Local $hFileOut = FileOpen($sFile, 2)
FileWrite($hFileOut, $sHex)
FileClose($hFileOut)
Return $sFile
EndFunc

[/autoit]

Gruß

Prajoss

**BugFix**

Zitat von chip

dann könntest auch ganze Setups, Filme ect. in eine sqlite prässen was an den Grundgedanken hinter einer sqlite bzw. andere DB komplett vorbei geht und jedem Design Pattern Konzept wiederspricht.

Hier scheint sich ein Glaubenskrieg zu entwickeln.
Ich würde dir hier zu 100% widersprechen. Denn du schränkst, wenn ich das richtig verstehe, das Arbeitsgebiet von Datenbanken damit auf den Web-Raum ein. Dieser Raum ist. z.B. für mich im Zusammenhang mit DBs ohne jedes Interesse. Und ich arbeite sehr viel mit Datenbanken.
Der evtl. Geschwindigkeitsverlust durch große Daten-Volumina (was noch genauer zu untersuchen wäre) fällt meiner Meinung nach kaum ins Gewicht. Eine DB wird eigentlich nur ausgebremst durch unsaubere Indexierung, nicht bereinigte Leerdatensätze und dergleichen. Selbst die Anzahl Datensätze kann heute problemlos in zig- oder hunderttausende gehen ohne das spürbar die Bremse angezogen wird. Das ist ja der große Vorteil von SQL.
Also einigen wir uns auf einen Status Quo: Eine Datenbank kann auch problemlos direkt Mediendaten aufnehmen. - Wer das nicht mag, läßt es einfach.

**chip**

Zitat von BugFix

Denn du schränkst, wenn ich das richtig verstehe, das Arbeitsgebiet von Datenbanken damit auf den Web-Raum ein.

Habe ich mit keinem Wort gesagt. Sondern lediglich dass es nicht sind der Sache ist alles auf biegen und brechen in eine sqlite zu pressen, vor allem wenn die optimale DB für Dateien das Filesystem ist ;). Und btw. Design Patterns ist nichts Webspezifisches ;).