Bilder in (Firebird-)Datenbank speichern

[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

[jobo]

Deine Maxime mag für Dich gelten. Ich tendiere da eher zu der Äußerung von ibexpert, das muss von Fall zu Fall entschieden werden. (Bedeutet in der Praxis vielleicht auch eine vereinheitlichte, abgesprochene, abgestimmte, generalisierte Kompromisslösung.)
Deine Argumente verwischen auch meinen Kompromissvorschlag, das vielleicht Beste aus beiden Welten zu nehmen. Eine DB die Zugriffssicherheit und Fehlerschutz bietet und ein Dateisystem hinter der DB, das Schnelligkeit und Ressourceneffizienz bietet.
Datenbanken mit all ihrem Luxus kommen mit dem Preis des Ressourcenverbrauchs (Platz, Zeit). Die Existenz von noSQL Systemen ist der lebende Beweis dafür. Das gilt auch und besonders beim Backup bzw. noch mehr bei der Restauration eines Backups, am deutlichsten bei einem Point in Time Recovery mit sequentiellem Einspielen der Änderungen. Ich kenne die Mechanismen von FB nicht sehr genau, aber bei anderen Systemen ist es meist so, dass parallel zu den Datenbankdaten auch Wiederherstellungsinformationen geschrieben werden, also eigentlich alles doppelt. Diese Daten werden dann wiederum beide durch Backupverfahren aufgegriffen.
Administrative Maßnahmen wie eine Auslagerung von Dateidaten in eine weitere DB sind ebenfalls nicht ohne Fehlerpotential, besonders wenn es sich um manuelle Vorgänge handelt. Wie dabei ein Bildarchiv ständig Daten aufnehmen kann, aber nicht gesichert werden muss, erschließt sich anhand der Beschreibung auch nicht. Wenn das alles durchautomatisiert ist, meinetwegen auch okay. Einen hochperformanten Zugriff über FS und entsprechende Cachemechanismen habe ich damit immer noch nicht.
Herausragende Fehl“administration“ ist im Einzelfall erschreckend, aber das ist schwerlich ein Argument für oder gegen etwas. Ich kann für jedes Verfahren irgendwelchen Irrsinn finden, der es beschädigt. Das ist natürlich alles relativ, aber Datenspeicherung per FS im direkten Zugriffsbereich des Endanwenders ist dagegen schon ziemlicher Horror. Ich habe jedenfalls in langer Praxis noch nicht erlebt, dass Administratoren eine Console öffnen, sich als DB User oder als root an einem Server einer fremden Software anmelden und Dateien verschieben, verändern oder löschen.
Wenn durch ein SQL Interface Daten in einem Server unerreichbar verschwinden und dahinter geschützt im Dateisystem gespeichert werden, ist es gut. Im Fall, den ich beschrieben habe, kann ich für jede Datei wählen oder grob konfigurieren, wo am Ende gespeichert wird, wenn ich möchte auch beides, DB und FS. Das ist ja das Schöne, die Datenbank erlaubt einen sehr filigranen Umgang mit den hochgeladenen Daten. Das FS dahinter bringt einfach Speed und Raum für Nach- und Weiterverarbeitung mit einem riesigen Fundus an frei verfügbaren, fertigen Werkzeugen. Wer den puren Schutz in der DB vorzieht, kann das so machen, sollte die Nebeneffekten aber wenigstens kennen.

[TBx]

@jobo: Es tut mir leid, wenn Du Dich persönlich von meinem Post angegangen fühltest.
Dies war nicht meine Absicht.
Ich verwische allerdings keinesfalls Deine Argumente, ich gehe nur halt nicht wirklich mit ihnen mit.
Den Tutorials von Holger habe ich im Allgemeinen nichts hinzuzufügen, alles weiter wären Feinheiten, die im Einzelfall besprochen werden müssen. Daher werde ich das hier jetzt nicht weiter aufrollen.
Nur soviel: Der Ressourcenoverhead hält sich beim Firebird da sehr in Grenzen (eine richtige Konfiguration vorausgesetzt, die ich dem Kunden automatisch mitgebe) und an Geschwindigkeit steht der FB dem Filesystem da auch in nichts nach.

[jobo]

Ich fühle mich nicht persönlich angegangen. Alles gut.
Hier gibt es nun genug Material, was Interessenten als Anregung für eigene Überlegungen und Experimente nutzen können.