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

[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.

[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.

[jobo]

Hybridlösungen hatte ich ja bereits vorgeschlagen. Aber hier läuft man jenach Umsetzung Gefahr Inkonsistenzen zu bekommen. Besonders wenn die Dateien lokal auf dem System liegen. Ist wahrscheinlich hier unporblematisch, weil kein echter Verlust, wird halt neu generiert, wenn ein Bild (versehentlich) verschoben/gelöscht wurde.

[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.

[MichaelT]

War bei einer Instandhalteranwendung in der Voest Linz / Stahl auch sehr beliebt und ist es vermutlich immer noch.

Wenn eine Anlage zu reparieren ist muss es schnell gehen und sehr viele Menschen fassen gleichzeitig Materialien aus. Die nn Delphi entwickelte Lösung lief einfach. Selbst als 'das Netzwerk' (ein Teil) ausfiel wurde die DB Datei einfach auf einen anderen Server kopiert und es konnte weitergearbeitet werden.

Bei großen Schuppen wird gerne auch probiert mit SAP zu arbeiten, damit Replikation wird eingespart. Im SAP war was auf eine Delphi Maske mit TabControl passte in SAP 20 Dialogen abgebildet (im SAP). Eigenentwicklung in ABAP wurde abgelehnt, da selbst der einfachst gestaltete Prototyp besser lief als die Standardtransaktionen und das kann nicht sein.

Deswegen kommt man ohne Delphi nicht durch oder zumindest .net hilft schon. Oft sind politische Entscheidungen der Enabler für andere.

Solche straighten Lösungen sind beliebt solange die DB zumindest nicht zu oft und per Anwendung kann reorganisiert werden. Was mit wieder zum Punkt bringt, dass die DB schnell zu sichern sein sollte und gegebenfalls from Scratch der Generierungsprozess eilig reproduziert werden muss können. Wenn mal was wäre, dann wird auf den Codezwerg hingehackt von den Benutzern.

OT:Zumal man seit dem gestern Rider IDE habe probiert neben Go-Land muss ich sagen langsam bilden sich auch komfortable Alternativen für die Entwicklung auf der Serverseite mit gelegentlichem GUI heraus.

Ersatzhardware muss nicht immer gleich schnell sein. Das ist zwar heute nicht mehr so das Thema. Je größer die Datenbestände des schwieriger das Backup usw... und damit singt auch die Willigkeit ein Backup ...

50k neue Sätze im Jahr auf einer großen Tabellen und du weißt warum die Oracle so viele Optionen hat bei so manchem Statement.

Zitat von mensch72:

nutzen ein Zukauftool. (Letztendlich eine "SingleFileEngine", welche Single/Multiuser, Compress/Crypto und SimpleIndex/SQLselect sauber und wirklich schnell selbst löst)