Datenbank für schnelle Bilder, Vorschläge bitte.

[Daniel]

Man kann vieles machen, wenn man denn möchte. Aber er fragte halt nach einer DB - und so völlig abstrus ist der Gedanke ja auch nicht, für eine Datensammlung eine Datenbank nutzen zu wollen.

[Jumpy]

Oder halt eine Kombination von beidem, wie bei einem Dokument-Verwaltungs-System?

Die Dateien liegen (ggf. unter einem kryptischen Namen) in einem dafür ausgelegten Filesystem.
In der Datenbank ist dieser Ablageort samt Dateinamen gespeichert, zusammen mit den Attributen, durch die das Bild ggf. zugeordnet werden soll.
Die DB ermöglicht nun eine schnelle Suche, ob es das Bild (zu gewissen Werten o.ä.) schon gibt und liefert den Ort, von dem es geladen werden kann.

[mkinzler]

Wenn Datenbank, würde ich alles in diese speichern.

[KodeZwerg]

Zitat von Daniel:

er fragte halt nach einer DB - und so völlig abstrus ist der Gedanke ja auch nicht, für eine Datensammlung eine Datenbank nutzen zu wollen.

Ja Danke dafür, also DB ist schon das Ziel, alle Fileserver oder kryptische Dateinamen o.ä. Möglichkeiten kenne ich, vielen Dank für alle Dateisystem basierten Vorschläge aber die scheiden partout aus. Vorgabe ist eine DB oder etwas was die Funktionen die ich brauche schnell bereitstellen kann. Es gibt ja auch virtuelle Dateisysteme, darüber habe ich auch schon nachgedacht, was da halt performanter wäre im Vergleich zu einer DB. Das wäre für mich die einzige alternative, so das lokal nur ein paar Zusatzdateien entstehen aber die Bilder in einer großen zusammengefasst werden (bei virtuellem Dateisystem wahrscheinlich dann egal).

[rokli]

Hallo,

vielleicht teilst Du Deine Daten in 2 Bereiche:

1. Verwaltung in einer DB/Tabelle -> Name des Bildes, ID des Bildes, weitere Informationen insbesondere zum Suchen und in der
2. DB/Tabelle -> die Bilddaten mit ihrer ID.

Der Vorteil ist, dass Deine Verwaltung schlank bleibt und beim Suchen von Bildern mit wenigen Daten ausgekommen wird.

Gruß

[mkinzler]

Blobs werden aber sowieso gesondert gespeichert. in der eigentlichen Tabelle wird nur ein Verweis(BLOBID) gespeichert.

[KodeZwerg]

Zitat von mkinzler:

Blobs werden aber sowieso gesondert gespeichert. in der eigentlichen Tabelle wird nur ein Verweis(BLOBID) gespeichert.

Das beantwortet schon mal eine meiner Fragen wo ich noch am lesen/lernen der Doku bin, was mein Grundkonzept, weil ich es nicht besser wusste, bereits allen Wind aus den Segeln nimmt
Ich muss mich da einmal durchlesen und mir dann letztendlich ein Gutes Konzept ausdenken.
Ich breche an dieser Stelle mal ab bevor hier noch ein Streit wegen meiner Unwissenheit entsteht.
Erstmal werde ich nun als Hausaufgabe lesen/lernen/Konzept planen auf haben und melde mich bei Fragen zurück.
Vielen Dank für all Eure Verschiedenen Ansätze mir helfen zu wollen und es tut mir leid wenn ich mich falsch Ausdrücke!

[MichaelT]

Du wirst vermutlich ein wenig auf die Größe von Änderungslogs der DB gegebenenfalls aufpassen müssen.

Je nachdem möglw. hilft eine zeitliche Partitionierung. Zumindest ein Poor Mans's Partitioning könnte gegebenfall helfen. Eine View macht ein UNION über Tabelle mit Einträgen über bspw. einen Zeitraum. Aber das vermutlich nicht wirklich gehen, sonst bräuchtest du vermutlich nicht die Voranzeige.

Pfade in der DB sind nicht unbedingt immer gut, sobald Benutzer die Möglichkeit haben umzustrukturieren. Eine Filesystem ist ein hierarchische DB (ala LDAP).

Habe ich das richtig verstanden. Du speicherst so eine Art 'Thumbnails'/Vorschaubild von größeren Dateien ein der DB zur Ansicht und willst nicht die Datei holen.

Du hast keine Chance das Processing des Bilds von 5 Sekunden zu beschleunigen?

Zitat von KodeZwerg:

Zitat von mkinzler:

Blobs werden aber sowieso gesondert gespeichert. in der eigentlichen Tabelle wird nur ein Verweis(BLOBID) gespeichert.

Das beantwortet schon mal eine meiner Fragen wo ich noch am lesen/lernen der Doku bin, was mein Grundkonzept, weil ich es nicht besser wusste, bereits allen Wind aus den Segeln nimmt
Ich muss mich da einmal durchlesen und mir dann letztendlich ein Gutes Konzept ausdenken.
Ich breche an dieser Stelle mal ab bevor hier noch ein Streit wegen meiner Unwissenheit entsteht.
Erstmal werde ich nun als Hausaufgabe lesen/lernen/Konzept planen auf haben und melde mich bei Fragen zurück.
Vielen Dank für all Eure Verschiedenen Ansätze mir helfen zu wollen und es tut mir leid wenn ich mich falsch Ausdrücke!

[KodeZwerg]

Hallo, in der DB soll kein Pfad, nur der Name der Datei als Referenz + dessen CRC + ein/zwei Bilder.
.....ich könnte auch auf Name verzichten und nur noch CRC als Referenz nutzen, aber da würde ich nicht Wissen wie ich einen Eintrag wieder los werde (wenn Original Datei fehlt).....
Ziel: Es soll auf gar keinen Fall "extern" angefangen werden Bild-Dateien wild zu schreiben, ob mit System oder nicht -> das ist ein No-Go.
Konzept: In Planung.
Der Programm Ablauf ausführlicher Erklärt:
Haupt .exe hat verschiedene Funktionen, unter anderem eine Bild-Analyse.
Die Bild-Analyse ist realisiert durch eine Dll an der wir arbeiten.
Die Übergabe an Dll erfolgt als Handle + Namen + Boolean, es wird ein Bild als Result wiedergegeben oder dessen Fehler-Code.
Das Handle ist ein Stream, der Name wird aufs Bild projeziert und der Boolean steuert welchen Bild-Typ generiert werden soll.
Die Berechnung selbst erfolgt bereits multi-threaded und ist auf gleicher Höhe wie bei Konkurenzprodukten.

Das was ich gerne hätte wäre Vergleichbar vom Prinzip mit so etwas:
Ein Ordner mit sehr viel Bild-Dateien für die Du einen Betrachter programmierst der eine Thumbnail Datenbank intern verwendet/verwaltet um eine schnelle Vorschau präsentieren zu können. Ich brauche als Result halt immer nur eines dieser Thumbnails und nicht alle wie beim Betrachter Beispiel.

edit
Zu dem No-Go:
Es gab bereits eine alpha-phase in der wir pro Datei ein Bild generierten was intern über Meta-Daten gesteuert wurde, funktionierte auch tadellos aber der Vorschlag wurde abgelehnt.

[TigerLilly]

Mir fällt da MediaMonkey (der MP3 Player/Verwalter). Da hast du die Verwaltungsdaten in der Datenbank, die Datei aber im Filesystem.

Das würde ich hier ebenso machen. Zigtausend Bilder IN der Datenbank zu haben bläht die Datenbank unglaublich auf. Deine DB bekommt da ja eine beachtliche Größe! Eigentlich geht es dir ja nur darum, den Zugriff auf das Bild zu beschleunigen. da ist die DB schon gut, aber bitte nicht die Bilder selbst auch drin speichern. Nur den Pfad, das genügt.