AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Bilder in (Firebird-)Datenbank speichern

Bilder in (Firebird-)Datenbank speichern

Ein Thema von Frickler · begonnen am 22. Okt 2020 · letzter Beitrag vom 25. Okt 2020
Antwort Antwort
Seite 2 von 3     12 3   
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
480 Beiträge
 
FreePascal / Lazarus
 
#11

AW: Bilder in (Firebird-)Datenbank speichern

  Alt 22. Okt 2020, 19:01
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 ...
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
IBExpert and Firebird Power Workshops jederzeit auch als Firmenschulung

Geändert von IBExpert (22. Okt 2020 um 19:30 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
37.044 Beiträge
 
Delphi 10.4 Sydney
 
#12

AW: Bilder in (Firebird-)Datenbank speichern

  Alt 23. Okt 2020, 00:08
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (23. Okt 2020 um 10:03 Uhr)
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.901 Beiträge
 
Delphi 2010 Enterprise
 
#13

AW: Bilder in (Firebird-)Datenbank speichern

  Alt 23. Okt 2020, 08:57
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.
Gruß, Jo
  Mit Zitat antworten Zitat
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
480 Beiträge
 
FreePascal / Lazarus
 
#14

AW: Bilder in (Firebird-)Datenbank speichern

  Alt 23. Okt 2020, 09:27
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
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
IBExpert and Firebird Power Workshops jederzeit auch als Firmenschulung
  Mit Zitat antworten Zitat
Frickler

Registriert seit: 6. Mär 2007
Ort: Osnabrück
291 Beiträge
 
Delphi XE6 Enterprise
 
#15

AW: Bilder in (Firebird-)Datenbank speichern

  Alt 23. Okt 2020, 12:41
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).
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.659 Beiträge
 
Delphi 10.4 Sydney
 
#16

AW: Bilder in (Firebird-)Datenbank speichern

  Alt 23. Okt 2020, 12:51
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
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
480 Beiträge
 
FreePascal / Lazarus
 
#17

AW: Bilder in (Firebird-)Datenbank speichern

  Alt 23. Okt 2020, 13:27
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"...
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
IBExpert and Firebird Power Workshops jederzeit auch als Firmenschulung
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
37.044 Beiträge
 
Delphi 10.4 Sydney
 
#18

AW: Bilder in (Firebird-)Datenbank speichern

  Alt 23. Okt 2020, 13:48
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (23. Okt 2020 um 13:58 Uhr)
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.901 Beiträge
 
Delphi 2010 Enterprise
 
#19

AW: Bilder in (Firebird-)Datenbank speichern

  Alt 23. Okt 2020, 20:29
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.
Gruß, Jo
  Mit Zitat antworten Zitat
TBx
(Moderator)

Registriert seit: 13. Jul 2005
Ort: Stadthagen
1.783 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#20

AW: Bilder in (Firebird-)Datenbank speichern

  Alt 25. Okt 2020, 11:35
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
Gruß Thomas
- Moderator Delphi-Praxis -
- Admin Delphi-Treff
- Embarcadero MVP
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:34 Uhr.
Powered by vBulletin® Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2020 by Daniel R. Wolf