Bilder in (Firebird-)Datenbank speichern

[IBExpert]

Zitat von jobo:

In der DB finde ich das auch nicht so toll. Eine DB ist halt kein Fileserver

ja, genau und wenn das filesystem readwrite sein muss und nicht readonly sein kann, aus welchen Gründen auch immer
und dutzende Clients in Netzwerk da auf die Dateinamen und Attribute zugreifen müssen, weil die da mit dem
Explorer darauf arbeiten, entsteht dadurch schon mal eine Menge reiner I/O traffic und was in vielen Fällen
noch schlimmer ist, ein freundlicher Trojaner deiner Wahl räumt die Inhalte da gerne mal auf, egal auf welchem
der angeschlossenen Systeme das über die Dateifreigabe dann ausgelöst hat. Wenn es so was wie
Filesystemtrigger BeforeUpdate geben würde, könntest du immer noch den alten Inhalt sichern
bevor der überschrieben wird, im Netzwerk war es das dann oft mit dem brauchbaren Inhalt der Datei ...

Ein Trojaner, der sich in der Datenbank anmeldet und dann alles löscht, kenn ich so nicht, falls das doch mal
passiert, nennt man den, der das veranlasst hat, zwar vorne auch Tro aber das Wort geht hinten mit ttel weiter

Weitere Aspekte dafür, so was in der DB zu machen: Echte Transaktionsfähigkeit, keine echten Limits was die Anzahl
der Records betrifft, beliebige viele zusätzliche Attribute und Foreignkeys, Realtime Hot Backup ohne
Trickersei wären schreibvorgänge weiterlaufen, uvm.

Es muss aber jeder für sich bewerten, in kleinen Datenmengen ist der Mehraufwand gegenüber dem Filesystem
vielleicht doch zu hoch, aber die Vorteile überwiegen bei großen Datenmenge erheblich. Daher gab es das aber auch
ja von mir als Video, basiert auf Praxiserfahrungen ...

[himitsu]

Ja, das mit "einer" Transaktion wäre schon was Nettes.
Wir/Ich hatte schon ganz schön kämpfen müssen, um Dateien und deren Datensatz synchron zu halten,
also beim speichern/löschen/ändern an einer Seite bei Problemem die andere Seite passend zu bekommen,
z.B. beim Importieren kann es ja im Dateisystem (Schreibrechte oder fehlende Ordner/Freigaben), der Datenbank (Trigger) oder bei den Nutzerrechten im Client irgendwo was knallen und es wäre unschön, wenn dann die Datei oder der Datensatz halb zurück bleibt, wenn etwas der Anderen knallte.



Das böse Microsoft baut grade die Transactionen wieder aus.
Dateisystem und Registry

Angeblich haben es zu wenige genutzt und ich war die letzten Jahre auch noch nicht dazu gekommen, wobei ich es auch erst vor "paar" Jahren fand.


Nja, im NAS nitze ich Btrfs ... schnelle Snapshots, wo beim Schreibzugriff und Löschen die Dateien gesichert werden (CopyOnWrite)

Btrfs im Windows ist leider nicht so super/sicher supported (da arbeitet praktisch nur Einer dran) und ReFS oder was es sonst noch so gibt.
Aber Möglichkeiten gibt es Viele, um Dateien hinter einer Netzwerkfreigabe auch mit Schreibzugriffen schützen zu können, was direkt im Windows nicht so leicht möglich ist,
aber auch lokal mit einer kleinen LinuxVM oder über einen angepassten Dateiserver, welcher die Dateien entsprechend revisioniert.

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

[mkinzler]

Zitat:

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.

Am Besten die Gehirn-Engramme zusätzlich ablegen

[IBExpert]

Zitat von mkinzler:

Zitat:

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.

Am Besten die Gehirn-Engramme zusätzlich ablegen

oder statt langweiliger OCR mal Max Kleiner und seinen Beitrag
"MACHINE LEARNING MIT CAI"
in real benutzbare informationen umsetzen.

Softwaregestützte Objekterkennung ist sicherlich spannend für Leute
mit viel Zeit und Spaß an Verfahren der künstlichen Intelligenz, leider
sind oft die Ergebnisse im praktischen Einsatz eher das Gegenteil sprich
"Natürliche Dummheit"...

[himitsu]

Wie war das mit der KI, der man beibrachte teure von billigen Autos zu unterscheiden?

Alles lief gut, bis auffiel, dass sie KI nicht die Autos unterschied, sonden nur gelernt hatte "teure" Autos wurden bei schönem Wetter fotografiert und waren sauber
und dann kam mal eine saubere Schrottkiste bei Sonnenschein vorbei.

MACHINE LEARNING kann viel, aber da es dir nicht sagen kann, warum es so entschied, weiß man auch nicht, ob es wirklich das macht, was es soll.

Aber um "ähnliche" Bilder zu suchen, da sind dann kleine Fehler nicht ganz so schlimm, wenn es nur als Vorauswahl für den Menschen dient.

[jobo]

Zitat von 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 ....
..

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

..

Ok, wieder zu knapp ausgedrückt.
Ich spreche von einem System, dass tatsächlich für Anwender nur als DB über IPort bzw. vergleichbare spezifische Verbindungsparameter erreichbar ist. Da macht niemand was per FTP (sowieso Horror), Explorer o.ä.

Die Daten bzw. die Datein gelangen nur per SQL in das System. Das System ist ansonsten für Anwender nicht erreichbar.

Falls doch, muss es ein Admin mit entsprechenden Rechten sein, mit expliziter Anmeldung als Admin und der hat dann einen fatalen Fehler begangen, wenn er versehentlich Dateien verschiebt oder überschreibt. Fatale Fehler als Admin können aber auch mit einer DB passieren.

Auch dann gibt es diverse Möglichkeiten, damit umzugehen, angefangen bei eindeutigen Dateinamen, unabhängig von gespeicherten Pfadangaben und Links in der DB. Eine Verschiebung ist damit rekonstruierbar (ohne Backup), erst ein Löschen von Dateien oder das Ändern benötigt dann zur Rekonstruktion ein Filesystem Backup (Das dann für einzelne Dateien ausreichend ist). Ein gespeicherter Hash kann dabei jederzeit zur Prüfung genutzt werden. Dateizugriffsrechte können auch nur dem DB User gegeben werden. Ein Admin mit anderen Rechten muss dann schon waghalsige Sachen anstellen, um fremde Dateien zu zerstören.

Warum man Windows mit Explorer und "versehentlich verschoben" als Server freiwillig verwendet, erschließt sich mir auch nicht. Aber das ist ein anderes Thema. Ich weiß, dass bei Kunden alles vorkommt was denkbar ist und noch mehr. Aber die Kunden sind auch diejenigen, die möglichst wenig für eine effiziente und sicher Implementierung ausgeben wollen. Man hat also auch da Argumente.
Wer darauf besteht, Gigabyte oder Terrabyte an Daten auf w10 home zu managen, der soll es machen. Ich würde da für nichts garantieren.

Es empfiehlt sich für den DB Server der Einsatz eines Linux Systems, am besten gleich headless- ohne grafischen "Explorer". Hier bekommt man auch diverse Filesysteme geschenkt, ein Dutzend gängige, aber "notfalls" auch Hunderte andere. Das geht auch mit Firebird.
MS weiß sicher sehr genau, warum es unter der Haube WSL einführt und immer mehr Produkte für Linux anbietet.

Wenn man so ein System implementiert, ist der Aufwand für versionierte Dateiverwaltung auch ziemlich gering. Es wird vomn System gar nicht mehr überschrieben, nur eingefügt. Verkürzt, man lässt die Update Implementierung weg. Gerade für Firebird Kenner dürften die Prinzipien dazu bekannt sein.

[TBx]

Was sich mir persönlich an dem ganzen Filesystemgehampel nicht erschließt ist, warum ich mir die Mühe machen soll, etwas sicher und konsistent zu machen, wenn ich das in der DB automatisch habe.
Möchte ich Daten aufteilen, weil ich z. B. bestimmte Teile immer wieder auslagern möchte oder bestimmte Teile (Bilderarchiv z. B.) nicht ständig in der DB-Sicherung haben will, packe ich die in eine weitere Datenbank und greife immer nur über die Hauptdatenbank darauf zu. Da muss ich dann nichts mehr konsistent halten, das macht das System automatisch für mich. Dateinamen für Auslagerungen/Übergaben an andere Programme werden on the fly generiert.
Da brauch ich mir nicht viel Gedanken machen. Und durch den dann fest vorgegebenen Weg kann mir auch kein anderer Entwickler das System versaubeuteln. Wie oft habe ich schon darüber gebrütet, warum irgendwelche Daten an total unsinnigen Stellen abgelegt waren. Oftmals hat es sich dann jemand mal wieder einfach gemacht und einfach so die Daten gespeichert, wie das die aufs Formular geklatschte Komponente eben von Hause aus macht.
So hole ich die Daten von einem definierten Ort und stelle sie der Komponente/dem Fremdprogramm im erwarteten Format zur Verfügung und sichere die Daten danach in meiner Datenbank in meinem Format definiert wieder weg. Und keiner manipuliert dann noch was an meinen Daten rum.
Hab da mal nen Admin gehabt, der war der Meinung TIFF-Dateien sind doof. Also hat er die alle in jpeg gewandelt. Die Darstellung im Programm funktionierte nach wie vor, aber OCR u. ä. machte die Grätsche. Da ist es dann auch Wurst, ob der Admin ja selbst schuld ist. Ich als Entwickler kriege das Problem erst mal auf den Tisch und muss mich im schlimmsten Fall für Umme drum kümmern.
Daher ist meine Maxime: Alle Daten gehören für alles und jeden außer meiner eigenen Anwendung gesichert und verborgen.

Just my 2Ct