Fotospeicherung mit SQL

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Antworten
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Fotospeicherung mit SQL

Beitrag von ramses »

Tom hat geschrieben: Mo, 14. Jun 2021 11:25 Wir werden Ende des Jahres dazu übergehen, auch alles andere, was wir im Moment noch in klassischen Ordnerstrukturen halten (Einstellungen, Dokumente, Bilder usw.) in die Datenbanken zu überführen. Und dann schauen wir mal, wie lange wir DBF und ADS und PG parallel supporten.
Hallo Tom

wollt Ihr echt Bilder (Binär) in die Datenbank packen??
Sind das grosse Dateien und wieviele? Einige kB oder MB pro Bild und 100 erte oder viele 10'000 Bilder?
Valar Morghulis

Gruss Carlo
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Fotospeicherung mit SQL

Beitrag von Tom »

Hallo, Carlo.

Es geht um Mitarbeiter- und Patientenfotos, und um Bilder, die zu Patientendokumentationen gehören, etwa Wundfotos. Das sind überschaubare Mengen.

Auf die Auflösung haben wir keinen Einfluss. Ich nehme an, wir bewegen uns im Normalfall in den üblichen Smartphonefotogrößenordnungen, also irgendwas zwischen zwei und acht MB je Bild.
Herzlich,
Tom
Benutzeravatar
dtmackenzie
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 265
Registriert: Do, 22. Nov 2007 9:02
Wohnort: Leipzig
Hat sich bedankt: 66 Mal
Danksagung erhalten: 22 Mal
Kontaktdaten:

Fotospeicherung mit SQL

Beitrag von dtmackenzie »

Hallo Tom,

sehe ich auch so. Der Bereich "Filter" hat mir wahrscheinlich die meiste Arbeit gekostet.

Zu Deinem Problem mit dem Mandanten - ein extra Feld "Mandant" in jeder Tabelle (NULL für allgemein?) würde ich nicht unbedingt als schlimm ansehen. Wenn der akt. Mandant global in Postgres sichtbar festgelegt ist, könnte man vielleicht die Tabellen umbenennen und stattdessen Views benutzen, die genau wie die jetzige Tabellen heißen und aussehen (ohne Mandant-Feld), und die die WHERE-Klausel (Mandant IS NULL OR Mandant = CurrentMandant) drin haben. Das könnte vielleicht ohne weitreichende Code-Änderungen funktionieren, oder? Zumindest solange PGDBE auch damit zurecht kommt...
Viele Grüße,
David
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Fotospeicherung mit SQL

Beitrag von Tom »

Wir haben alle möglichen Varianten in Erwägung gezogen, auch Tabellennamen und eben das Identifizierungsfeld (was den bestechenden Vorteil hat, dass sich Daten für mehrere Mandanten zugleich relativ problemlos anzeigen lassen, aber es hat noch mehr Nachteile, vor allem im Performance- und im Wartungsbereich). Namespaces/Schemas wären eigentlich optimal. Aber wir fangen einfach die entsprechenden Kommandos ab und ordnen das jetzt den Connections zu. Das geht (vermutlich) auch ziemlich gut. Wir müssen nur in unserem Repository nachschauen, wo die Tabellen hingehören.
Herzlich,
Tom
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Fotospeicherung mit SQL

Beitrag von ramses »

Tom hat geschrieben: Mo, 14. Jun 2021 12:08 Auf die Auflösung haben wir keinen Einfluss. Ich nehme an, wir bewegen uns im Normalfall in den üblichen Smartphonefotogrößenordnungen, also irgendwas zwischen zwei und acht MB je Bild.
Hallo Tom

die Auflösung könntest du mit Tools schon ändern. In einer App lege ich immer ein Thumbnail ein 1600*1000 Bild und noch das Originalbild an.

Habt Ihr schon Experimente mit dem Speichern von JPG's oder PDF's als Binäre Daten in PG gemacht?

Meine haben zwar funktioniert waren aber betreffend Performance, Speicherbedarf der Datenbank (min. doppelter Bedarf), Datensicherung und Umsetzung in Web-App alle samt nicht befriedigend, ja sogar geradezu deprimierend.
Valar Morghulis

Gruss Carlo
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Fotospeicherung mit SQL

Beitrag von Werner_Bayern »

Servus Carlo,

wir haben eine Anwendung, in der der Kunde bisher schon ca. 3000 Bilder in der SQL-Tabelle abgelegt hat. Ja, der physikalische Speicherbedarf ist wesentlich größer als das Jpg, aber das liegt ja in der Natur der Sache: Jpgs sind komprimiert, wenn man sie binär speichert, dann sind das die unkomprimierten Rohdaten.

Damit die Performance gut bleibt, zeigen wir auch immer wo es möglich ist, nur ein Thumbnail an. Das geht sehr schnell. Wird der entsprechende Datensatz dann geöffnet, oder ein Thumbnail angeklickt, wird per SQL das Bild aus der Tabelle geholt.

Fürs Abspeichern ins SQL haben wir eine Systemeinstellung, da kann der Kunde angeben, wir groß das Bild (MB) max. sein darf, ansonsten wird es um 50% verkleinert und mit 90% Qualität gespeichert. Das verkleinert ein Jpg mit 6 MB auf ca. 0,5 MB (je nach Kompressionsmöglichkeit) - ohne große, sichtbare Qualitätseinbuße.

Ohne SQL wäre das nicht möglich.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Fotospeicherung mit SQL

Beitrag von Tom »

Das mit den Fotos ist, wie ich oben angedeutet habe, bei uns noch auf der Agenda, aber dort nicht sehr weit oben - bislang werden die nach Gusto auf den Massenspeichern gehalten und in der Anwendung über Dateinamen und -pfade verlinkt. Aber das ist keine Kernfunktionalität, die zudem nicht von allen Kunden verwendet wird, und es geht auch nicht um etwas so hochfrequent genutztes wie Produktabbildungen. Deshalb sind wir da noch recht entspannt und für alle Lösungen offen. Es gibt einen Teilbereich der Versorgungs- und Wunddokumentation, wo es sich etwas anders verhält, aber dort sind wir mit der demnächst anstehenden Migration in die Telematik-Infrastruktur konfrontiert, und Datenquelle sind zumeist unsere eigenen Mobilanwendungen. In diesem Kontext wird eine dezente Performanceeinbuße beim Ablegen der Rohdaten in einem Blobfeld das geringste Problem sein. :wink:
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Fotospeicherung mit SQL

Beitrag von brandelh »

Werner_Bayern hat geschrieben: Mo, 14. Jun 2021 21:37 ca. 3000 Bilder in der SQL-Tabelle abgelegt hat. Ja, der physikalische Speicherbedarf ist wesentlich größer als das Jpg, aber das liegt ja in der Natur der Sache: Jpgs sind komprimiert, wenn man sie binär speichert, dann sind das die unkomprimierten Rohdaten.
das verstehe ich nicht, wenn die JPG in einem binären Feld gespeichert wird, sollte außer der Verwaltung die Byte-Zahl gleich bleiben, oder ? :?
Gruß
Hubert
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Fotospeicherung mit SQL

Beitrag von ramses »

Hallo Werner

Die Anzeige der Übersicht habe ich auch mit ThumbnailS gelöst. Wenn nur ein Anwender in der Übersicht blättert sind aber sofort sehr viele Datenbankzugriffe nötig um die Metadaten oder Thumbnail File zu laden. Dabei muss ja auch immer vom gespeicherten Hex Format nach Binär gewandelt werden.

Da war bis jetzt das Filesystem um einiges schneller besonders wenn mehrere Anwender gleichzeitig am Werk sind. Wenn dann der Browser die Datei in mehreren Teilstücken anfordert war die Performance über SQL derart im Keller.

Und das mit nur einem Bruchteil der vorhandenen Bildern. Ich habe mit etwa 300'000 Datensätzen was 900'000 gespeicherten Bildern entspricht getestet. (Thumb, Verkleinert, Original) Dabei habe ich noch nicht mal die richtigen Originale von 45MB verwendet sondern schon auf 4 MB reduzierte.

Wie habt Ihr das hinbekommen dass die Performance über SQL besser ist als durch das Filesystem gelesene Files und du zum Schluss kommst ohne SQL gar nicht möglich????

( Einige PG Profis raten mir ständig davon ab grosse Binäre Datenbestände in PG zu speichern.)
Valar Morghulis

Gruss Carlo
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Fotospeicherung mit SQL

Beitrag von ramses »

brandelh hat geschrieben: Di, 15. Jun 2021 9:07 das verstehe ich nicht, wenn die JPG in einem binären Feld gespeichert wird, sollte außer der Verwaltung die Byte-Zahl gleich bleiben, oder ? :?
Hallo Hubert

Die Daten in ByteA Feldern werden im Escape oder Hexformat gespeichert. Was immer einem mehrfachen Platzbedarf entspricht.

siehe:
https://www.postgresql.org/docs/14/datatype-binary.html
Valar Morghulis

Gruss Carlo
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Fotospeicherung mit SQL

Beitrag von brandelh »

ich .... klar die müssen ja damit rechnen, dass die Daten weltweit abgerufen werden.

muss man das Format aus Xbase++ heraus selbst erzeugen, also die Bilddatei einlesen und mit HEX() ? umwandeln und das "\x" voran setzen ?
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Fotospeicherung mit SQL

Beitrag von Tom »

Nein, das macht die DBE. Du speicherst Binärdaten und bekommst sie auch wieder zurück.
Herzlich,
Tom
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Fotospeicherung mit SQL

Beitrag von Werner_Bayern »

ramses hat geschrieben: Di, 15. Jun 2021 9:24 Wenn nur ein Anwender in der Übersicht blättert sind aber sofort sehr viele Datenbankzugriffe nötig um die Metadaten oder Thumbnail File zu laden.
Wie habt Ihr das hinbekommen dass die Performance über SQL besser ist als durch das Filesystem gelesene Files und du zum Schluss kommst ohne SQL gar nicht möglich????
( Einige PG Profis raten mir ständig davon ab grosse Binäre Datenbestände in PG zu speichern.)
Servus Carlo,

wir machen alles über Pass-Through, kein ISAM-SQL. In der SQL-Tabelle sind die Bilder und auch gleich die Thumbnails (werden beim Speichern der Bilder gleich mit erzeugt) abgelegt. Für das Browse wird also ein select auf die Thumbnails abgefeuert, das ist sehr schnell. Da ist also nur 1 select für das komplette Browse nötig.
Deshalb auch die Aussage, dass das ohne SQL nicht möglich wäre: ISAM-SQL oder DBFNTX liest ja mindestens immer einen Satz komplett ein, mit SQL kann ich die Felder bestimmen, die ich pro Satz brauche.

Die Aussage der PG-Profis ist für mich eine Glaubensfrage. Ich wüsste nicht, wie man das vernünftig ohne die Speicherung der Bilder in SQL lösen könnte.

Hier einige Eckdaten von PostgreSQL:
Maximale Datenbankgröße: unbegrenzt
Maximale Größe einer Tabelle: 32 Terabyte
Maximale Größe eines Datensatzes: 1,6 Terabyte
Maximale Größe eines Feldes: 1 Gigabyte
Was bitte spricht da gegen die Speicherung von Bildern in einer SQL-Tabelle?
es grüßt

Werner

<when the music is over, turn off the lights!>
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Fotospeicherung mit SQL

Beitrag von ramses »

Hallo Werner

Hauptsächlich werden immer genannt:
Das Speichern Binärer Daten in der Datenbank ist aufgrund des benötigten Speicherplatzes, der benötigten umwandlung in Hex-Codierung und der Zugriffszeit ineffizient. Zudem ist das Erstellen von Backups aufgrund der Dateigröße von Datenbanken mit Biären Daten sehr zeitaufwendig.

Ich kann das teilweise sogar glauben. Angenommen in fülle die im Projekt vorhandenen Bilder mit ca. 30 TB Grösse in die Datenbank benötigt diese infolge der Hexcodierung ca. 60 TB plus die eigene Grösse von 30 GB.

Bei einem Upgrade der Version der Datenbank benötigt das Backup/Restore vermutlich so viel Zeit dass dies nicht mehr vernünftig möglich ist.

Ich verwende keine Xbase PG Funktionen sondern eine eignen Klasse mit Aufrufen der libpq das ist auch schnell.

Das schöne an der Lösung mit speichern der Binären Daten in der PG Datenbank wäre dass keine Laufwerksverbindung zum Server mehr nötig wäre und Samba, und Rechteverwaltung auf dem Daten-Server wegfallen könnte.
Deshalb nehme ich das Thema immer mal wieder hervor um nach einer Lösung zu suchen.

Einen Tip bekamm ich auch noch: verwende wenn schon nicht den bytea Datentyp sondern Large Object mit den funktionen lo_create usw. die können anscheinend direkt Binäre Daten verarbeiten ...... kennst du die?
Valar Morghulis

Gruss Carlo
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Fotospeicherung mit SQL

Beitrag von Werner_Bayern »

Servus Carlo,

alles korrekt, bei Deiner Menge ist das absolut zu berücksichtigen. Aber, ohne SQL hast halt einen erheblich größeren manuellen Verwaltungsaufwand.

Wir hatten kürzlich die Anforderung, Service-Mitarbeiter mit Notebooks die SQL-Tabellen lokal zu kopieren, da die nicht immer eine Internetverbindung beim Kunden vor Ort haben. Wir haben einfach in unsere SQL-Klasse pg_dump und pg_restore integriert und schon ist alles da. Kompletter Offline-Betrieb ist möglich. Läuft seit 2 Monaten beim Kunden.

Nein, mit lo_create() arbeiten wir bisher nicht.
es grüßt

Werner

<when the music is over, turn off the lights!>
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Fotospeicherung mit SQL

Beitrag von ramses »

Hallo Werner

ja der Verwaltungsaufwand ist etwas höher das lässt sich aber sehr gut automatisieren und auf Verzeichnisse aufteilen und über rsync sehr viel schneller verteilen als dies pg_dump macht.

Ich habe gestern mit den lo_??? Funktionen getestet. Die sind auch nicht die Lösung. Sie wären zwar "Streaming" fähig die Daten werden aber allesamt auch im Hexformat zentral in der Postgres eigenen Datenbank in der Tabelle pg_largeobject gespeichert und die Performace ist noch schlechter als mit Bytea Feldern. Leider funktionieren die lo_import und lo_export nicht wie gewünscht weil die Doc ist hier in einem sehr wichtigen Punkt ungenau.

Die Performance:
aus einem Bytea Feld lesen 4-6 fache Zeit verglichen mit Filesystem
aus einem Large Objekt Feld lesen 8-10 fache Zeit verglichen mit Filesystem
je nach Dateigrösse.

Danke für deinen Input. Er hat mich dazu gebracht das Thema gründlich anzugehen.
Ich komme zum selben Schluss wie die PG-Profis die ich zitiert habe: Eine Datenbank ist kein Filesystem ....
Valar Morghulis

Gruss Carlo
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Fotospeicherung mit SQL

Beitrag von Tom »

Für uns sind geringerer Verwaltungsaufwand und geringere Fehleranfälligkeit (bzw. Anfälligkeit gegen Nutzereingriffe von außen) die schlagenden Argumente dafür, den - in unserem Kontext, wie erwähnt, auch überschaubaren - Bilderbestand ganz direkt in Feldern für binäre Datenobjekte zu speichern. Einen ebenso überschaubaren Performanceverlust sowie mehr Speicherbedarf können wir hier sehr lässig in Kauf nehmen. Vermutlich werden wir aber eine Systematik implementieren, die die Bildauflösung begrenzt, also die Bilder ggf. herunterrechnet (in den Mobilapps bei der Lieferung von Personen- oder Dokumentationsfotos geschieht das bereits). Wir hatten einen Fall, da hatte ein Profi-Fotograf einem Kunden Mitarbeiterbilder in fantastischer Auflösung und mit hoch zweistelligen Einzelgrößen geliefert, und diese Bilder sind dann in einer mäßig performanenten Netzwerkstruktur an mehreren Stellen direkt verlinkt worden, was einige Prozesse, äh, negativ beeinflusst hatte.

(BTW, möglicherweise sollte man diesen Thread trennen und ab der Trennstelle in "Fotospeicherung mit SQL" umtaufen.)
Herzlich,
Tom
Benutzeravatar
Marcus Herz
1000 working lines a day
1000 working lines a day
Beiträge: 851
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 39 Mal
Danksagung erhalten: 192 Mal
Kontaktdaten:

Fotospeicherung mit SQL

Beitrag von Marcus Herz »

-Fotospeicherung ...
Sicher immer ein aktuelles Thema. Tom hatt ja gezeigt, wie man mit dem Alaska Asset sich mit einem anderen Benutzeraccount anmelden kann. Damit können ja Fotos nur über kontrollierte Links in einem geschützen Ordner geöffnet werden. Quasi ein Ansatz von Datenschutz
Gruß Marcus

Erkenne, was du findest, dann weißt du, wonach du gesucht hast
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Fotospeicherung mit SQL

Beitrag von brandelh »

Tom hat geschrieben: Do, 17. Jun 2021 9:30 (BTW, möglicherweise sollte man diesen Thread trennen und ab der Trennstelle in "Fotospeicherung mit SQL" umtaufen.)
Dein Wunsch war mir Befehl, ich hoffe ich hab alles richtig hin bekommen ;-)
Gruß
Hubert
Benutzeravatar
Lewi
1000 working lines a day
1000 working lines a day
Beiträge: 830
Registriert: Di, 07. Feb 2006 14:10
Wohnort: Hamburg
Danksagung erhalten: 2 Mal

Re: Fotospeicherung mit SQL

Beitrag von Lewi »

Mit dem Projekt https://www.medbox.org stand ich auch vor der Entscheidung, ob PDF`s und Bilder in eine DB (NoSQL-MongoDb) gespeichert werden sollen oder eben nicht. Bei 30.000 Datensätzen besteht ein Speicherbedarf auf der Festplatte von ca. 120GB. Schlussendlich aber ich mich aus folgenden Gründen für eine Verzeichnis/Datei-basierte Lösung entschieden:

- Möglichkeit von sequenziellen Backups für externe Dateien. Allein das Einspielen der Dateien im Umfang von 120GB auf einen Web-Server kann mit 10MB/S Upload-Geschwindigkeit schon mal eine Woche dauern.
- Ferner steigen die Ressourcen-Anforderungen und damit die Kosten für Replica-Sets (Spiegelung von Datenbanken)
- Im Zuge der Entwicklung wurde die DB wegen Anpassungen und Performance-Test vom Entwicklungsrechner auf den Web-Server hin und her übertagen. Bei 120GB hätte das jedes Mal Tage gedauert.

Viele Grüße
Olaf
Benutzeravatar
nightcrawler
1000 working lines a day
1000 working lines a day
Beiträge: 650
Registriert: Di, 24. Apr 2012 16:33
Wohnort: 72184 Weitingen
Hat sich bedankt: 3 Mal
Danksagung erhalten: 96 Mal
Kontaktdaten:

Re: Fotospeicherung mit SQL

Beitrag von nightcrawler »

Das sind durchaus gute Argumente und man muss immer im Einzelfall entscheiden. Bei der Speicherung innerhalb der Datenbank hat man u.a. die Vorteile:
  • Transaktionssicher
  • Konsistentes Backup
--
Joachim
Joachim Dürr Softwareengineering
https://www.jd-engineering.de
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Fotospeicherung mit SQL

Beitrag von Jan »

Gerade das zweite Argument von Joachim ist der Grund, warum ich manchmal die Bilder in einer Tabelle speichere. Wobei eher noch wichtiger ist das ich damit den Anwendern auch die Möglichkeit nehme, da manuell irgendwas weg zu löschen, zu verschieben, was auch immer.

Wobei natürlich immer die Abwägung besteht wie groß die Tabelle dann wird/werden kann, und ob dadurch entstehende andere Nachteile überwiegen würden. Bilder in einer Tabelle sind halt nicht immer die beste Idee. Aber doch oft.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1991
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fotospeicherung mit SQL

Beitrag von Herbert »

Aufgrund der geforderten DIgitalisierung von allen Dokumenten, führen wir alle Scans, auch Bilder, in den SQL-Tabellen. Das Ganze ist aber so organisiert, dass die Tabellen, aufgesplittet momentan in 4 Tabellen, für sich alleine stehen, damit keine riesengross wird. Eine Kontrolltabelle ergänzt mit Zusatzinformationen (auch Passworte, Stichworte, Kategorien usw.).
Bei der Sicherung kann auf diese Weise mit oder ohne Dokumente gearbeitet werden, um die Performance zu halten.
Grüsse Herbert
Immer in Bewegung...
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Fotospeicherung mit SQL

Beitrag von ramses »

Unsere Lösung ist ein wenig anders:
Aufgrund der geforderten DIgitalisierung von allen Dokumenten, führen wir die Metadaten/Prüfsumme der Files von Scans, Herstellungs-Dok un überwachungs / Prüfbiler -Bilder, Rechnungen usw. in den SQL-Tabellen. Das Ganze ist aber so organisiert, dass die Files Jahreweise in herkömmlichen Verzeichnissen gespeichert werden auf welche der User keinen direkten Zugriff hat. Das vereinfacht die Sicherung ungemein. Die vergangenen Jahre müssen nicht mehr jedes mal mitgesichert werden.
Valar Morghulis

Gruss Carlo
Benutzeravatar
Lewi
1000 working lines a day
1000 working lines a day
Beiträge: 830
Registriert: Di, 07. Feb 2006 14:10
Wohnort: Hamburg
Danksagung erhalten: 2 Mal

Re: Fotospeicherung mit SQL

Beitrag von Lewi »

Für beide Ansätze gibt es Pro`s und Contra`s.
Ein Vorteil bei Speicherungen von von Images in eine DB ist sicherlich die Einbeziehung von Transaktions-Management-Techniken.

Die wesentliche Nutzung von Transaktions-Flows ist deren Verwendung wegen seiner Atomarität in einem Online-Prozess. In diesem Modus ist die Geschwindigkeit der Datenbank ein begrenzender Faktor dafür, wie viele Transaktionen Sie in einer bestimmten Zeit verarbeiten können. Wenn die Datenbank große binäre Blobs (Images, Videos usw.) bereitstellt, bedient sie KEINE wichtigen Transaktionen.

Das Backup-Management ist bei einer File-basierten Image-Speicherung weniger Ressourcenintensiv, weil sequentielle Backup-Strategien eingesetzt werden können. In meinem Fall hat die DB eine Größe von ca. 1GB, währenddessen 150 GB für Images anfallen.
Was die Vorteile der Konsistenz bei Datenspeicherungen betrifft, so halte ich dies eher für eine akademische Diskussion.

Meines Erachtens überwiegen aber die Nachteile, wenn Images in DB gespeichert werden:
Ein Image als Blob oder Base64-codiert in einer SQL-DB zu speichern hat keinen besonderen Nutzen. Das Feld kann weder Indiziert noch nach Informationen abgefragt werden. Was die DB-Engine betrifft, werden Ressourcen ohne zusätzlichen Nutzen in Anspruch genommen.
Wenn Bilder in einer Datenbank abgelegt sind und Abfragen über ganze Datensätze (SELECT * FROM) gehen, ist das bei lokalen Client-Server Anwendungen oder bei Anwendungen im eigenen Netzwerk kein Problem. Solche Anfragen über WEB-CGI oder VPN können Performance-seitig massive Auswirkungen haben, wenn sich von außen z.B. über eine 3G Verbindung ins Firmennetz eigenwählt wird. 1 MB für eine Bilddatei fallen dabei schon ins Gewicht. Deshalb ist darauf zu achten, dass die Anfragen „schlank“ bleiben.

Im Zusammenhang mit dem Web ist zu beachten, dass ein Web-Server nur über begrenzte Arbeitsspeicher-Ressourcen verfügt. Ein Zugriff auf Dateien im File-System direkt und statisch braucht weniger Ressourcen als eine dynamische Lösung bei dem erst Images in den Arbeitsspeicher via SQL-Abfrage geladen und anschließend für die Ausgabe verarbeitet werden müssen und das gleichzeitig bei -zig Sessions.

Bei Anbietern von Medien-Verwaltungslösungen, die ich kenne, werden Meta-Informationen zu einem Image/Video in eine Datenbank abgespeichert, die Dateien selbst File-basiert.

Viele Grüße
Olaf
Antworten