Discussion:
Bilder in Datenbanken-Sinnvoll ?
(zu alt für eine Antwort)
Bernhard Herlemann
2004-06-24 09:24:52 UTC
Permalink
Hallo,

ich hatte gestern wieder eine Diskussion,
ob es sinnvoll ist Bilder(eingescannte Unterlagen) in Datenbanken zu
speichern.

In diesem speziellen Fall würde der Foxpro Client auf eine mySQL Datenbank
zugreifen.

Meiner Meinung bringt es viele Nachteile, die Bilder in BLOB's oder ähnlich
zu speichern,
-->Es besteht einen grösser Gefahr, dass die Daten inkonsitent werden, ohne
dass man es merkt.
-->Wichtig ist auch das Thema Datensicherung.
Eine Datensicherung kann m.M. nach mit einzelnen Bildern zeitlich effektiver
realisiert werden,
als mit einer ganzen Datenbank.

Die Gegenargumente waren, dass durch Verwendung von BLOB's nur die Datenbank
gesichert werden müsste,
was konzeptionelle einfacher wäre. Und dass es mittlerweile "üblich" wäre
Dokumente in Datenbanken zu speichern.


Wollte mal Fragen wie die Meinung in der NG ist.

Gruss

Bernhard
n.Olivier
2004-06-24 09:42:07 UTC
Permalink
Hi
Post by Bernhard Herlemann
Hallo,
ich hatte gestern wieder eine Diskussion,
ob es sinnvoll ist Bilder(eingescannte Unterlagen) in Datenbanken zu
speichern.
Nein
Post by Bernhard Herlemann
In diesem speziellen Fall würde der Foxpro Client auf eine mySQL Datenbank
zugreifen.
Und, sollte dies einen Unterschied machen?
Post by Bernhard Herlemann
Meiner Meinung bringt es viele Nachteile, die Bilder in BLOB's oder ähnlich
zu speichern,
-->Es besteht einen grösser Gefahr, dass die Daten inkonsitent werden, ohne
dass man es merkt.
Lässt sich mit ein paar Zeilen Code vermeiden
Post by Bernhard Herlemann
-->Wichtig ist auch das Thema Datensicherung.
Eine Datensicherung kann m.M. nach mit einzelnen Bildern zeitlich effektiver
realisiert werden,
als mit einer ganzen Datenbank.
Datenbank ist ein Bier, das Daten/Serververzeichnis ist ein anderes
Post by Bernhard Herlemann
Die Gegenargumente waren, dass durch Verwendung von BLOB's nur die Datenbank
gesichert werden müsste,
was konzeptionelle einfacher wäre. Und dass es mittlerweile "üblich" wäre
Dokumente in Datenbanken zu speichern.
Nun, es ist auch "üblich" daß immer mehr Menschen immer mehr zu sich
nehmen,
weniger Bewegung haben und daher Übergewichtig sind.

Eine Datenbank sollte schlank sein.
Unter bestimmten Voraussetzungen kann es jedoch auch sinnvoll sein,
Dokumente in der DB zu speichern z.B.: Textsuche in den Dokumenten

gruß n.Olivier
--
Nachbagauer Olivier
Technologiezentrum Freilassing
D-83395 Freilassing
www.nOlivier.com
www.Reedb.com - Immobilien Online
Holger Vorberg
2004-06-24 10:07:15 UTC
Permalink
Hi,
Post by Bernhard Herlemann
ich hatte gestern wieder eine Diskussion,
ob es sinnvoll ist Bilder(eingescannte Unterlagen) in Datenbanken zu
speichern.
nun ja, das wird dann auch sicherlich hier eine Diskussion auslösen.

Eigentlich müsste man die Frage stellen, warum man Bilder NICHT ein einer
Datenbank speichern sollte.
Denn Grundsätzlich spricht erstmal nichts dagegen. Auch Bilder, Töne usw.
sind Daten und Datenbanken sind nicht nur zum Speichern von Buchstaben und
Zahlen gedacht.

Die Gründe, die gegen ein Speichern in einer FoxPro oder, noch schlimmer,
Access Datenbank sprechen, gelten aber nicht unbedingt für andere DBs.

Ich persönlich mache da grundsätzlich einen Unterschied zwischen File/Server
Datenbanken und Client/Server Datenbanken und würde aus Erfahrung keine
Bilder mehr in File/Server Datenbanken speichern, sondern nur noch einen
Verweis auf die eigentliche Bild Datei. Ausserdem ist man mit Bildern, die
in der DB gespeichert werden, sehr schnell an der 2GB Grenze !!

Bei Client/Server Umgebungen ist das anders. Mal abgesehen von deren
üblicherweise geringen Ausfallquoten durch Beschädigungen an der Datenbank,
würde man dort einen Bruch mit der Client/Server Philosophie machen, wenn
man statt der eigentlichen Bilder nur noch einen Pfad speichern würde. Der
Pfad müsste zunächst mal physisch existent sein (also dann doch wieder
File/Server) und dann auch noch für alle Benutzer identisch.
--
Tschüß,

Holger Vorberg
MS Visual FoxPro MVP
dFPUG Regionalleiter Bielefeld
Bernhard Herlemann
2004-06-24 10:38:38 UTC
Permalink
Post by Holger Vorberg
Hi,
Bei Client/Server Umgebungen ist das anders. Mal abgesehen von deren
üblicherweise geringen Ausfallquoten durch Beschädigungen an der Datenbank,
würde man dort einen Bruch mit der Client/Server Philosophie machen, wenn
man statt der eigentlichen Bilder nur noch einen Pfad speichern würde. Der
Pfad müsste zunächst mal physisch existent sein (also dann doch wieder
File/Server) und dann auch noch für alle Benutzer identisch.
Hallo Holger,

und wie sieht es mit der Belastung/Performance der Datenbank aus, wenn die
doch recht grossen Bilder aus der Datenbank geholt werden.

Die Netzwerkbelastung wird ja in beiden Fällen ähnlich sein.

Gruss

Bernhard
Holger Vorberg
2004-06-24 12:56:53 UTC
Permalink
Hi,
Post by Bernhard Herlemann
und wie sieht es mit der Belastung/Performance der Datenbank aus, wenn die
doch recht grossen Bilder aus der Datenbank geholt werden.
schwer zu sagen, die Netzwerkbelastung ist IMHO spürbarer.
--
Tschüß,

Holger Vorberg
MS Visual FoxPro MVP
dFPUG Regionalleiter Bielefeld
Bernhard Herlemann
2004-06-24 10:48:26 UTC
Permalink
Kann man das ganze mit Webseiten mit einem Photo-Schwerpunkt vergleichen.
Bei mir bekannten Realisationen (allerdings PHP) werden die Photos nicht in
Datenbanken abgespeichert.
Was allerdings auch PHP-spezifische Gründe haben kann.

Gruss
Bernhard
Christoph Dreßler
2004-06-24 15:25:17 UTC
Permalink
Hi,

ich kann nur raten, das einstellbar zu machen. Für C/S-betrieb _muss_
der Speicherort die DB sein, sonst ist ein Verweis auf Dateien viel
performanter, ich habe das leidvoll erfahren müssen.

Wir realisieren das so: es gibt Binary-Memofelder, die einen Header
fester Länge enthalten (Dateiname, Pfad, anderen Kram) und danach
optionen eben den "Content" oder nichts weiter.

Die Verwaltung (Anzeige in Masken, Einfügen, Löschen, Druckfunktionen)
hängt auch von der zentrale Option "Speicherort" (DB/<Verzeichnis>)
ab. Sogar ein Konvertieren der Betriebart ist damit recht elegant
möglich.

Viel Erfolg,
Christoph

Lesen Sie weiter auf narkive:
Loading...