Bilder für Server in Datenbank ablegen...

[SubData]

Guten Morgen (Gott is das noch früh -gähn-)

Diskutieren wir doch mal über den Sinn und Unsinn über das Ablegen von Bildern in einer Datenbank.

Ich arbeite derzeit an einer Intranet-HTTP-Server-Lösung, die auch eine gewisse Menge von Bilddateien bereit stellt (Etwa 200 Stück, ca. 3 - 4 MB) und mir geht es darum, dass der Endbenutzer diese Bilder hinterher nicht verändern / austauschen kann. Wenn ich die Bilder direkt mit über ServeFile weitergebe, werden sie ja von der Festplatte gelesen, nun möchte ich allerdings gerne, dass die Bilder aus einer Datenbank kommen.
Es wäre theoretisch kein Problem die Bilder zur Startzeit des Servers alle aus der Datenbank zu laden und ein Record (oder Array?) oder sonst irgendwas in der Art zu schreiben und diese dann zur Abfragezeit auszugeben.
So wäre nicht bei jedem Aufruf eine Datenbankverbindung notwendig.
Die Frage hierbei ist allerdings ob es sinnvoll ist eine Kette von TMemoryStream zu erzeugen um die Bilder im Speicher zu halten oder ob es da andere (elegantere?) Lösungen gibt, den Benutzer daran zu hindern die Bilder zu editieren (Nein Hash Summen auf die Datei kommen dabei nicht in Frage -g-).

Zusätzlich hätte es den Vorteil, dass ich nicht 200 Dateien mitliefern muss sondern nur die Datenbank, die sowieso bereits vorhanden ist.

Was wäre die eleganteste, performanteste und am besten umzusetzende Lösung für ein solches Vorhaben?


In der Hoffnungen niemanden zu so früher Stunde mit meiner Frage zu überfordern...

[Sharky]

Hai SubData,

ändern sich die Bilder denn häufiger oder bleiben es "immer" die selben?

[Edit]
Brauche die bilder zusammen 3-4 MB oder jedes einzelne davon?

[SubData]

Also in der fertigen Version sind es bis zu nem Programmupdate immer die Selben.

Zusammen 3 - 4 MB... Es sind nur lauter kleine Icons und Buttons

Edit: Derzeit ist es noch nichtmal 1 MB, aber da der Server noch nicht vollständig fertig ist und wahrscheinlich noch viele Funktionen und Seiten dazu kommen, schätze ich, werden es so ca. 3 - 4 MB

[Sharky]

Ich versuche das eben gerade mal so:

Mit einem Programm lade ich mir die Bilder in einen Stream. Dabei merke ich mir pro Bild die Startposition (offset) und die gröze (size).
Dieser Stream wird dann gespeichert. In einer extra Datei stehen alle Bilder mit Offset und Größe.

In der eigentlichen Anwendung wird die Bilddatei dann in einen Stream geladen. Wenn nun ein bestimmtes Bild benötigt wird, kann man es durch die Angaben von Offset und größe aus dem Stream kopieren und anzeigen.

Ich weiss aber noch nicht ob es geht ;-)

[SubData]

Hey die Idee ist wirklich gut...

Die Frage ist da nur die Performance, wenn man am laufenden Band von einer Position zur anderen des Streams springt.
Kann da jemand näheres drüber sagen?

[Sharky]

Zitat:

Zitat von SubData

... Die Frage ist da nur die Performance, wenn man am laufenden Band von einer Position zur anderen des Streams springt.
Kann da jemand näheres drüber sagen?

Da der Stream ja nur einmal von der HD geladen wird sollte das überhaupt kein Problem machen. Du setzt ja immer nur einen "Pointer" auf eine Position im Stream.

[SubData]

Somit dürfte es also auf jeden Fall schneller sein, als jedes Mal die Datei von der HD zu laden... Seh ich das richtig?

[Sharky]

Zitat:

Zitat von SubData

Somit dürfte es also auf jeden Fall schneller sein, als jedes Mal die Datei von der HD zu laden... Seh ich das richtig?

Naja, eine Speicheroperation dürfte sicher um den Faktor n * 100 schneller sein als jeder Zugriff auf eine HD.

Also denk ich es ist schneller ;-)

[marabu]

Obwohl das Thema Speicherung in der Datenbank für euch ja schon abgehakt zu sein scheint: Bei Verwendung einer Bilddatenbank würde sich die Frage nach Sinn oder Unsinn gar nicht erst stellen. Bei einer relationalen Datenbank wird von allen Herstellern darauf hingewiesen, dass variabel lange Daten auf die Performanz drücken. Angenommen ein Bild ist nach sauberer Datenmodellierung Attribut einer Entity. Die Speicherung als BLOB kann dann aufgrund der Segmentierung schnell zu einer unangenehmen Fragmentierung führen - weiterer Performanzverlust. Klar - habt ihr alles gewusst - aber vielleicht liest ja jemand mit.

Wegen der anderen Anforderungen (Eleganz, etc.) würde ich das Problem durch einen dedizierten Image-Server lösen. Das kann eine ISAPI Anwendung sein, die die Bilder bei Bedarf aus dem Dateisystem lädt und in einem eigenen Cache hält. Der Schutz dieser Bilder vor Manipulation wird durch diesen Ansatz aus der eigentlichen Anwendung heraus gehalten. Ich werde diese Technik bald in einem digitalen Archiv zum Einsatz bringen, wo es wichtig ist, dass die im Web veröffentlichten Bilder authentisch sind. Der Image-Server kann die Athentizität anhand eines vorher berechneten und in einer Tabelle gespeicherten Schlüssels prüfen. Alternativ können die Bilder in einem geschützten File-Container ausgeliefert werden, quasi ein eigenes Dateisystem in einer Datei. Sogar ZIP könnte für dich eine Lösung sein.

Grüße vom marabu