Bilder in (Firebird-)Datenbank speichern

**haentschman**

Moin...

Zitat:

wir wollen Bilder in einer Firebird-Datenbank speichern

...würde ich nicht machen. Bei der Datensicherung mußt du immer alle 24GB+ sichern. Bei den Bildern im Ordner mußt du ggf. nur die geänderten Bilder sichern oder die Sicherung unabhängig von der DB Sicherung laufen lassen.

PS:
Denkst du auch an den Entwickler? Wenn der Entwickler die Datenbankstruktur ändern muß, muß er beim Testen der neuen Statements, es geht nie beim ersten Mal glatt, immer die 24GB+ Datenbank wiederherstellen.

Der kann sich dann den halben Tag Kaffee holen...

**bernau**

Zitat von haentschman:

Moin...

Zitat:

wir wollen Bilder in einer Firebird-Datenbank speichern

...würde ich nicht machen. Bei der Datensicherung mußt du immer alle 24GB+ sichern. Bei den Bildern im Ordner mußt du ggf. nur die geänderten Bilder sichern oder die Sicherung unabhängig von der DB Sicherung laufen lassen.

Dann hat aber jeder direkten Zugriff auf die Dateien. Das ist ggf nicht gewünscht, da auf dem Server ggf nur der Firebird-Port geöffnet ist.

Mit der großen Datenbank habe ich auch so meine Probleme und in folgendem Thread gefragt, ob man ggf. auslagern kann

https://www.delphipraxis.net/204179-...rschieben.html

Darauf hin hat Holger Klemt ein echt ansehnliches Video-Tutorial auf Youtube gestellt. Dabei werden Daten in eine weitere Datei ausgelagert, die dann readonly ist. Diese muss man also dann nicht mehr permanent sichern.

**IBExpert**

die größte db mit der ich aktuell regelmäßig zu tun hab, hat mit bildern und pdfs derzeit ca 600GB
über alle datenbanken hinweg sind das mehr als 2TB

mein Tip (kam glaub ich auch im Video): beim Zugriff auf die Blob Inhalte
die Client Anwendung nicht direkt auf die Tabelle zugreifen lassen, sondern
über den Umweg einer SP, die einen blob als Rückgabe parameter hat und eine
id o.ä. als eingabeparameter, weil du dann die clientseitige Implementation
immer nur ein mal machen musst, serverseitig aber die sp so umbauen kannst, das
die per execute statement on external auch auf andere (zB Read Only Archiv)
Datenbanken sogar auf anderen Servern zugreifen kannst, auch wenn deine
client app davon gar nichts weiss, muss die ja auch nicht.

**Frickler**

Zitat von haentschman:

PS:
Denkst du auch an den Entwickler? Wenn der Entwickler die Datenbankstruktur ändern muß, muß er beim Testen der neuen Statements, es geht nie beim ersten Mal glatt, immer die 24GB+ Datenbank wiederherstellen.

Der kann sich dann den halben Tag Kaffee holen...

Der Entwickler bin ich

insofern...

Zur Klarstellung: Das sind nicht unsere Bilder. Die meisten Kunden haben auch deutlich weniger davon, etwas 10-20% der Menge. Aber ein Kunde hat halt Massen davon.

Den Nachteil sehe ich eher darin, nicht mal eben die Bilder außerhalb der Software anschauen zu können. Wir haben Kunden, die nach Vorgängen suchen, indem sie den Bilderordner im Total Commander öffnen, nach Datum sortieren, und dann alle Bilder vom Zeitraum anschauen, ob da Bilder des gesuchten Vorgangs dabei sind...
Ich hatte schon überlegt, mit einem Listview einen Explorer zu faken, der dann die Bilder in der Datenbank so anzeigt, als seien diese in einem Ordner. Stelle mir das aber kompliziert vor.

**IBExpert**

Die Ansicht mal eben nach Datum sortieren, wenn es nur ein Pfad ist, sollte im Explorer im Filesystem kein them sein, selbst nicht mit der im Explorer vorhandenen Preview Ansicht.
Aber mach das einfach mal testweise mit wahlweise einer Millionen bilder in einem pfad oder auch in Unterpfaden, die geschwindigkeit vom filesystem gerade auf windows wird bei großen Datenmengen (im sinne von anzahl dateien) recht gemütlich, um das mal freundlich zu sagen.

Und von einem Zugriff auf die gleiche Ordnerstruktur über ein Netzwerk rede ich dabei noch gar nicht.

Es hindert dich ja auch keiner daran, in einem Filecache auf der Platte die native files abzulegen, das mach ich bei jeder zu öffnenden pdf Datei auch so, weil ich keine Lust hab, mit irgendwelchen Memory Streams halb funktionierende Komponenten und DLLs zu füttern, weil ich dafür ja sumatra als eigene exe einbinde, TImages aber direkt aus dem blob in die eigene Applikation zu ziehen und dort dann dazustellen, ist für png und jpg auch kein wirkliches Problem, aber erzeuge mal testweise auf einer Scrollbox zB 2000 TImages deiner Wahl und lade in alle ein anderes Bild aus dem Filesystem oder aus dem Datenbankblob. Bei png weiss ich ganz sicher, das das schnell mal 10-20 Sekunden dauert auch wenn nur ein Bruchteil davon sichtbar ist oder kleiner skaliert wird. Die Zeit verbrät aber nicht die lese/schreibe Operation sondern das decoding der Bilder. Da gibt es schnellere und langsamere TImage Varianten, aber zaubern können die alle nicht. Wenn du aber zB auf deinem Screen 10 Bilder nebeneinander darstellst und 5 Untereinander und eine unabhängige Scrollbar daneben baust, mit der man navigieren kann, wird das um längen schneller und dafür dann Bild 9950-10000 zu holen geht per sql befehl mit select first 50 skip 9950 * from ... und es fallen viele Overhead Operationen komplett weg, viele Webseiten arbeien übrigens ähnlich und auch da wird nix geholt was nicht explizit dargestellt werden soll.

Bei großen Datenmengen im Sinne von Anzahl Dateien und Bildern im Filesystem zu bleiben halte ich für eine Sackgasse, unter der gerade deinen Anwender mit großen Datenmenge leider werden, ich würde das niemals so machen.

**IBExpert**

ach ja, und bezüglich der Suche nach Datum, unser größter Kunde mit so einer pdf/png Archiv DB kann auch auf allen Dokumenten nicht nur nach dem Datum suchen oder einschränken, sondern hat in einem extra blob die erkannte OCR Volltext Inhalte des Dokuments bei scans oder bei pdfs das was als Text im pdf war, das hat sich insbesondere bei technischen Zeichnungen schon bewährt, weil oft in der Zeichnung schon Begriffe stehen, wo man was ähnliches sucht, geht in google ähnlicher Syntax, die aber die db auseinander nimmt.

Nur nach datum einschränken, dann würden die mir den Kopf abreissen ....

**himitsu**

Wenn einem die Datenbank-Dateien zu groß werden, dann könnte man die Tabellen auch noch partitionieren (aufteilen).

Dem Plattenspeicher selber ist es ja egal, ob die Dateien einzeln oder in einer großen DB rumliegen. (sind ja insgesamt gleich viele Bytes)

Wir hatten früher auch mal alle Dateien als Blob in der DB und jetzt liegen sie im Dateisystem.
Hat aber vorallem mit Gründen des Backups und einer revisionssicheren Speicherung (Unterstützung für ein WORM-Laufwerk) zu tun.
Und die Dateien werden hier in der DB-Verwaltet, zusätzlich mit HASH, um die Datenintegrität prüfen zu können, und dann werden sie über DataSnap vom Server rausgegeben, aber da geht auch jede andere Client/Server-Architektur.

In einigen DBMS kann man auch von der DB auf das Dateisystem des Servers zugreifen.
Rein theoretisch könnte man die Dateien dann in einer Tabelle verwalten und die Dateiinhalte statt in Blobs als einzelne Dateien speichern, aber sie dennoch über die DB-Verbindung speichern und abrufen, also z.B. beim Abruf der Tabelle als Blob anjoinen.

**jobo**

Zitat von himitsu:

In einigen DBMS kann man auch von der DB auf das Dateisystem des Servers zugreifen.
Rein theoretisch könnte man die Dateien dann in einer Tabelle verwalten und die Dateiinhalte statt in Blobs als einzelne Dateien speichern, aber sie dennoch über die DB-Verbindung speichern und abrufen, also z.B. beim Abruf der Tabelle als Blob anjoinen.

Das wollte ich mit meinem Beitrag gemeint haben.
Der Schreib & Lese Zugriff erfolgt transparent über SQL, einerseits für die reine Datei, andererseits für klassische Attribute und Zusatzinfos über den Vorgang. Dahinter liegt eine SP die das in Tabelle speichert und die Datei ins FS aussteuert. Sicher, transaktional, bequem, universell, Ressourcen schonend.
Durch die SP hat man wie schon genannt die Möglichkeit, auch weitere Nachverarbeitung, z.B. OCR + Volltextindizierung, what ever mit den Datein durchzuführen.

Die späteren Recherchemöglichkeiten sind top und können bei Bedarf auch noch mit einer REST Schnittstelle ergänzt werden. Hier hätte man durch das Speichern im Server seitige Dateisystem auch die Möglichkeit, ganz einfach klassische Cacheverfahren einzusetzen, diverse Systeme dafür gibt es ja geschenkt.

**IBExpert**

Im Filesystem sind aber mehrere beteiligt, daher bleibt es schwer
-jemand ändert mit der Anwendungssoftware eine Datei im Filesystem und sperrt diese dadurch, wer hat Kontrolle wann und wie die Sperre beendet ist?
-jemand lädt per ftp eine datei in das filesystem und die Übertragung wird unterbrochen, datei ist also nur halb da ...
-jemand verschiebt einen kompletten Ordner in einen anderen .. wie bekommst du technisch mit das es verschoben wurde und nicht delete und neue Dateien waren ....

das sind nur Teile mit denen ich mich konkret beim Filesystem als Referenz rumärgern musste, es ist auch nicht entweder oder, aber bei uns hat sich bewährt,
in der Datenbank ist die Referenz und für die meisten neuen Dateien gibt es definierte Importpfade und jobs im Hintergrund gleichen nach bestimmten Kriterien
die Inhalte in der DB mit denen im Filesystem ab, bearbeitung dieser Dateien beginnt aber aus der eigenen Anwendung, die dann den Blobsinhalt lokal als Datei ablegt,
dort die assoziierte Anwendung zu starten und sobald die datei nicht mehr zum Schreiben geöffnet ist, wird die neue Version mit der alten vergleichen und wenn
es sich geändert hat als neuer Blob in der db abgelegt, der alte bleibt je nach Regelwerk in der DB für x Versionen in der DB oder wird in die Archiv db übertragen
usw. Das passiert mit CAD Zeichnungsdateien, Office Dokumenten usw.

Außer der sowie verfügbaren tcp/ip firebird verbindung zum Serer brauch ich nichts anderes, egal wo der Anwender arbeiten möchte, ....

aber wie schon gesagt, ist mehraufwand als einfach nur Datei irgendwo liegen zu haben und nur den ort dieser Datei in die db zu packen, den Weg geh ich aber nicht, weil
das am ende niemals konsistent sein wird

**Frickler**

Zitat von IBExpert:

ach ja, und bezüglich der Suche nach Datum, unser größter Kunde mit so einer pdf/png Archiv DB kann auch auf allen Dokumenten nicht nur nach dem Datum suchen oder einschränken, sondern hat in einem extra blob die erkannte OCR Volltext Inhalte des Dokuments bei scans oder bei pdfs das was als Text im pdf war, das hat sich insbesondere bei technischen Zeichnungen schon bewährt, weil oft in der Zeichnung schon Begriffe stehen, wo man was ähnliches sucht, geht in google ähnlicher Syntax, die aber die db auseinander nimmt.

In einem dieser Fälle ging es um einen Reparaturauftrag, der gesucht werden sollte. Der Mitarbeiter, der den Auftrag suchte, wusste nur, wie der Artikel aussieht, aber keine anderen Daten (ja, sowas gibts!). Da beim Erfassen der Aufträge die Artikel von allen Seiten fotografiert werden, konnte er sich über die Bilder reinhangeln.

Und, ja, es ist auch schon vorgekommen, dass bei anderen Kunden Verschlüsselungstrojaner zugeschlagen haben und alle Bilder verschlüsselt. Die hatten glücklicherweise ein einigermaßen aktuelles Backup. Bei Bildern in der Datenbank kann das aber gar nicht passieren (es sei denn, der DB "Server" ist einfach ein weiterer PC im Netzwerk, auf dem sich der Trojaner austoben kann).