Daten in Datenbank Speichern?

[radiator007]

Hallo, ich hatte letztens eine hälftige Diskussion mit einen Kollegen darüber ob man Dateien in einer DB speichern sollte oder nicht. Wir sind dann so verblieben das es keinen Sinn macht außer bei wenigen ausnahmen, wie Web Anwendungen wo der admin keine Ordner Berechtigungen setzen kann oder bei Daten die sicher abgelegt werden sollen... wobei ich das auch nicht als Argument sehe.

Jedenfalls hab ich gestern schon wieder eine aussage bekommen das es doch überhaupt nix macht Dateien in eine Datenbank zu speichern auch wenn die dadurch in GB größe aufgebläht wird. Dabei handelte es sich um eine mysql Datenbank mit 6GB größe. Es handelte sich hierbei um ein Dokumentenmanagement System.

Von daher, was sagt ihr dazu. hab ihr ein paar gute Argumente warum Dateien in einer Datenbank überhaupt keinen Sinn machen? Oder liege bin ich derjenige der falsch liegt.

[lupo49]

Für mich stellt sich die Frage im Bezug auf ein Dokumentenmanagementsystem, wie willst du Dateien, die in einer Datenbank abgespeichert sind, aus der Datensicherung wiederherstellen? Bspw. wenn ein Benutzer eine Version überschrieben hat.

Bei einer filebasierten Sicherung gehe ich her und wähle in meiner Sicherungskonsole den Zeitpunkt und die Datei aus, wie soll das auf eine einfache(!) und zeitnahe(!) Weise gehen, wenn die Daten einer riesigen Datenbank gespeichert sind?

Ich finde gerade bei einem DMS bei dem du nicht weißt, wie viele Dateien in fünf Jahren sich angehäuft haben, sollten die Daten auf einem Dateisystem liegen. Schon allein der Grundgedanke ist für mich nicht nachvollziehbar.

[dbwizard]

Für mich stellt sich die Frage im Bezug auf ein Dokumentenmanagementsystem, wie willst du Dateien, die in einer Datenbank abgespeichert sind, aus der Datensicherung wiederherstellen? Bspw. wenn ein Benutzer eine Version überschrieben hat.

Bei einer filebasierten Sicherung gehe ich her und wähle in meiner Sicherungskonsole den Zeitpunkt und die Datei aus, wie soll das auf eine einfache(!) und zeitnahe(!) Weise gehen, wenn die Daten einer riesigen Datenbank gespeichert sind?

Ich finde gerade bei einem DMS bei dem du nicht weißt, wie viele Dateien in fünf Jahren sich angehäuft haben, sollten die Daten auf einem Dateisystem liegen. Schon allein der Grundgedanke ist für mich nicht nachvollziehbar.

Hallo,

Da kann man natürlich verschiedener Meinung sein. Welche Vorteile das Filesystem bei den von dir beschriebebn Cases gegenüber der Datenbank bietet, ist mir nicht ganz klar :

wie willst du Dateien, die in einer Datenbank abgespeichert sind, aus der Datensicherung wiederherstellen

-Das macht jede Datenbank auch (Ich gehe davon aus, dass in einer produktiven Umgebung auch deine Datenbank gesichert wird ?)

- Benutzt du Oracle, hast du z.b. auch die Möglichkeit, Flashback zu benutzten--> Stichwort Versionskontrolle und Historisierung

- Im Filesystem fehlt dir aber einige Dinge, welche in der Datenbank "mitgeliefert" werden :

> Transaktionskontrolle

> Skalierung

> Integration in dein restliches Datenmodel (Dokument stehen nicht alleine, es existieren Metadaten, Benutzerinformationnen, Logging etcetc...

Eine interssante Diskussion bei AskTom findest du hier :

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1011065100346196442

Gruss

[MartinSt]

Hallo,

Bspw. wenn ein Benutzer eine Version überschrieben hat.

das effektive Handling verschiedener Versionen eines Dokuments ist doch gerade der Vorteil beim DMS, während dieses auf OS-Ebene im Allg. eher mühsam zu bewerkstelligen ist.

Ich finde gerade bei einem DMS bei dem du nicht weißt, wie viele Dateien in fünf Jahren sich angehäuft haben, sollten die Daten auf einem Dateisystem liegen. Schon allein der Grundgedanke ist für mich nicht nachvollziehbar.

Man sollte sich bei der Konzeption eines DMS schon Gedanken drum machen, wieviele Daten pro Jahr zu erwarten sind.

Außerdem ist für mich ein Hauptargument gegen die Speicherung auf Dateisystemebene, dass ich im OS keine 100%ige Sicherheit gegen Veränderungen der Dateien habe.

Gruß Martin

[lupo49]

das effektive Handling verschiedener Versionen eines Dokuments ist doch gerade der Vorteil beim DMS, während dieses auf OS-Ebene im Allg. eher mühsam zu bewerkstelligen ist.

Ja, das ist theoretisch richtig. Nur viele Anwender überschreiben gerne vorhandene Versionen mit dem falschen Inhalt, anstatt eine neue Version anzulegen.

[dbwizard]

Ja, das ist theoretisch richtig. Nur viele Anwender überschreiben gerne vorhandene Versionen mit dem falschen Inhalt, anstatt eine neue Version anzulegen.

- Und was hilft dabei die Implementation in ein Filesystem oder eine Datenbank, wenn der Benutzer seine Use-Case falsch abhandelt ? Soclhe Sachen müssen über die Applikation geregelt werden, welche den Benutzer z.b. darauf hinweist, dass er eine bestehende Version überschreibt oder nicht

Gruss

[lupo49]

- Und was hilft dabei die Implementation in ein Filesystem oder eine Datenbank, wenn der Benutzer seine Use-Case falsch abhandelt ? Soclhe Sachen müssen über die Applikation geregelt werden, welche den Benutzer z.b. darauf hinweist, dass er eine bestehende Version überschreibt oder nicht

Gruss

Typisches Szenario:

1. Ich erstellen morgens ein Word-Dokument mit der Agenda für eine Besprechung => Version 1 des Dokuments.

2. Am nächsten Tag geht ein Kollege her, öffnet das Dokument, editiert die Daten und speichert das Dokument. Version 1 des Dokuments wird fälschlicherweise überschrieben.

3. Der Mitarbeiter aus Schritt 1 ruft bei der Hotline an und möchte dass sein Dokument, mit dem richtigen Inhalt, aus der Datensicherung wiederhergstellt wird.

Korrekt ist, dass der Anwender aus Schritt 2 sein Veränderung unter einer neuen Version hätte speichern müssen. Es sind halt Anwender.

[dbwizard]

Typisches Szenario:

1. Ich erstellen morgens ein Word-Dokument mit der Agenda für eine Besprechung => Version 1 des Dokuments.

2. Am nächsten Tag geht ein Kollege her, öffnet das Dokument, editiert die Daten und speichert das Dokument. Version 1 des Dokuments wird fälschlicherweise überschrieben.

3. Der Mitarbeiter aus Schritt 1 ruft bei der Hotline an und möchte dass sein Dokument, mit dem richtigen Inhalt, aus der Datensicherung wiederhergstellt wird.

Korrekt ist, dass der Anwender aus Schritt 2 sein Veränderung unter einer neuen Version hätte speichern müssen. Es sind halt Anwender.

- Ja, dass verstehe ich schon, nur ist dieses Problem nicht mit der Implemention Filesystem- Datenbank lösbar. Für solch ein Szenario sind aber Technologien wie Flashback (Oracle) ideal, um solche "Benutzerfehler" wieder zu korrigieren. Oder die Applikation sorgt für eine korrekte Speicherung (Warnhinweis bei Überschreiben, "automatische" Versionierung ...)

Gruss

[radiator007]

das effektive Handling verschiedener Versionen eines Dokuments ist doch gerade der Vorteil beim DMS, während dieses auf OS-Ebene im Allg. eher mühsam zu bewerkstelligen ist.

Warum ist es besser bei Versionierungen die Daten in Datenbanken zu speichern? Ist doch das gleiche als wenn ich nur den link zu der Datei hinterlege. Ja der vorteil liegt darin das ich mir bei der speicherung keine gedanken mache welchen Dateinamen die Datei hat aber kann das nicht beim upload von dateien berücksichtigt werden so das eine versionsnummer am dateinamen angehängt wird? Natürlich muss das im code die verschiedenen regeln für den upload und versionierung steuern sowas kann sicher kein dateisystem aber dann sollte es doch trotzdem besser sein die dateien in ein dateisystem zu speichern und nicht in eine datenbank.

[dr.dimitri]

aber dann sollte es doch trotzdem besser sein die dateien in ein dateisystem zu speichern und nicht in eine datenbank.

Ja die üblichen Legenden, die ihren Ursprung (wie sooft) in der mysql Welt haben.

Wer Dokumente über eine datenbankgetriebene Anwendungen zur Verfügung stellt, hat praktisch keine andere Wahl als diese auch in der DB abzulegen, sofern er recoverable, transaktionsfähig und hochverfügbar sein möchte.

Sofern man sich mit der verwendeten DB auskennt, gibt das auch keine Probleme was Perforance oder Implementierungsaufwand betrifft. Wir machen das u.a. auch im dezentralen Bereich (haben dort ca. 10Tsd Oracle SE1 Instancen auf den diversen Geräten laufen).

Die User können dort über die AW alle möglichen Dateien in der DB speichern (und tun das auch ausgibig).

Dim

[radiator007]

Ja die üblichen Legenden, die ihren Ursprung (wie sooft) in der mysql Welt haben.

heisst das das es bei mysql schon seinen sinn hat aber auf den "größeren" Datenbanken wie oracle und co besser ist die daten direkt in die Datenbank zu speichern?

[DocInfra]

MySQL ist nie dafür gedacht gewesen Binärdateien aufzunehmen. Ich will aber nicht ausschließen das es irgendwann mal ähnlich gut geht wie bei Oracle, DB2 oder MS SQL.

In meinen Augen ist es nicht sinnvoll Binärdateien in einer DB zu speichern. Besser wäre es Metadaten, Informationen und den Verweis auf die Binärdatei in einer DB zu speichern, die Daten selber aber im Dateisystem. Kommt auf das DMS an, um hier beim Beispiel eines DMS zu bleiben.

Wenn ich Informationen in einer DB speichere, dann sollten das Informationen sein, mit denen ich eine Binärdatei erstellen kann, also z.B. Informationen mit denen ich, über eine Funktion in der Anwendung, ein PDF oder $OUTPUT erstellen kann. Bei DMS ist das natürlich schwer, keine Frage. Hier liegen ja i.d.R. TIF Dateien o.ä. vor. Kommt halt starkt auf die Anwendung und das Umfeld an.

[dr.dimitri]

heisst das das es bei mysql schon seinen sinn hat aber auf den "größeren" Datenbanken wie oracle und co besser ist die daten direkt in die Datenbank zu speichern?

Ja. Wenn jemand der Meinung ist, Binärdateien sollten nicht in mysql gespeichert werden, dann ist das eine andere Aussage als wenn man die (leider immer noch) übliche Verallgemeinerung "Dateien gehören nicht in die Datenbank" verwendet.

In meinen Augen ist es nicht sinnvoll Binärdateien in einer DB zu speichern.

Wieso? Wenn die DB dafür geeignet ist was spricht dagegen?

Besser wäre es Metadaten, Informationen und den Verweis auf die Binärdatei in einer DB zu speichern,

Und wie regelst Du das dann mit dem Recovery, dem Locking (soll ja doch die ein oder andere Multiuseranwendung geben) und der Transaktionsfähigkeit?

Dim

[radiator007]

Ja. Wenn jemand der Meinung ist, Binärdateien sollten nicht in mysql gespeichert werden, dann ist das eine andere Aussage als wenn man die (leider immer noch) übliche Verallgemeinerung "Dateien gehören nicht in die Datenbank" verwendet.

Ich bin ja immernoch dabei mir eine meinung zu bilden. Aber in meinem ersten post hatte ich ja geschrieben das es im bei mir im moment um ein DMS geht welches dateien in eine MYSQL datenbank schreibt was ich nicht für sinnvoll halte. Dies war die hauptsächliche frage... natürlich hatte ich am ende diese etwas allgemein gefasst und von daher vieleicht etwas verwirrung gestreut.

Ich habe schon andere kommentare dazu und auch eine diskussion im oracle blog gelesen und von meiner meinung das es überhaupt keinen sinn macht schonmal abgelassen. Trotzdem werd ich wohl nochmal meine professoren an der uni fragen wie ihre meinung zu dem thema ist.

vieleicht bin ich jetzt etwas vorschnell aber eigentlich wollt ich nur meine aussage bestätigt bekommen das mysql dafür nicht gedacht ist und es auch nicht ratsam ist(DMS).

[Amstelchen]

viele datenbankhersteller (auch oracle) bieten gerade *das* spezifisch an, nämlich binärdaten wie dokumente, video und audio in der datenbank abzulegen - stichwort interMedia Audio, hier lautet der datentyp z.b. ORDSys.ORDAudio.

dass die daten natürlich im dateisystem liegen (wenngleich in einer tabelle resp. tablespace) ist wohl klar; dass diese natürlich transaktionssicher, recoverable, etc. sind, ist allerdings auch tatsache.

also bitte nicht kategorisch "nein" sagen, wenns um binärdaten in datenbanken geht.

s'Amstel