Alle Dokumentendateien in DB Speichern ? Vorteile / Nachteil

[Karstadt]

Hallo. Ich arbeite mit der Anwendung Centron. Diese Speichert die Daten (alle mögliche Dokumente) in ein e DB ab. Zum bearbeiten eines Dokumentes wird ein Dokument in Ordner Temp (xyz) gespeichert und dann beim beenden einer Anwendung (wie z.B. Word) werden die Änderungen in DB gespeichert und der Temporäre Ordner (xyz) wirt gelöscht

Nun mus ich eine ähnliche Aufgabe realisieren.

Meine Frage ist, wo sind die Vorteile bei so eine Methode? Unter Nachteilen stelle ich mir vor. (sehr Umständig, Datei aus DB auf die HDD speichern dann wider einlesen und bei X Dokumenten (mehrere GB) wird die DB irgendwann langsam)

Was haben Sie für Erfahrung gesamelt ?

[Phoenix]

Zitat von Karstadt:

Was haben Sie für Erfahrung gesamelt ?

Ui.... Ehrenwert. Aber bei uns Forum sind wir eigentlich alle gerne per Du

Vorteile der Datenbank-Speicherung:
- Rechtevergabe bei Dokumentbearbeitung: Es muss kein Netzwerk-Share für diese Dokumente angelegt werden und zusätzlich Berechtigungen verwaltet werden.
- Datensicherung: Backup der DB-> Alle Daten gesichert

Datenbanken sollten - so die denn richtig Konfiguriert sind(!) - selbst mit mehreren Terabytes an Daten keinen merklichen Performanceverlust zeigen. Zumindest mal Oracle und DB2 haben hier definitiv keine Probleme. Z.B. verwaltet eine größere amerikanische Versicherung wirklich _alle_ internen Dokumente in einem Oracle-basierten zentralen Dokumentenmanagement-System. Das sind etliche TB an Daten, und es fühlt sich so an als ob alles lokal liegen würde. Nungut, da steckt auch entsprechende Hardware dahinter, ab sowas setzt man dann einfach voraus.

Das auslesen und lokale Ablegen in der Datenbank ist kein großes Problem. Genau dafür sind Blobs ja da. Und das schreiben des Blobs auf die Platte und das zurücklesen sind auch jeweils eine Funktion mit ein paar Zeilen, also nahezu kein Aufwand.

Die Verwaltung, also das Locking der Dokumente ist da schon schwierigier. z.B. sollte ja nur immer einer gleichzeitig daran arbeiten können, weil sonst eine spätere Änderung die vorherigen überschreibt.

[mkinzler]

M.W. unterstützt MySQL keine echte Blobs (eigentliche Daten werden auch in der Tabelle gespeichert). Dies kann für ein bisschen Performenceverlust führen.
Es kommt u.U. auch auf die Sichtweise an: Willst du den Zugriff nur über dein Programm kontrollieren, dann ist die Speicherung in der DB besser, soll das nur eine variante sein, ist die externe Speicherung besser, da die dateien dann auch direkt bearbeitbar sind.
Ich würde aber die Speicherung innerhalb der DB präferieren.

[Karstadt]

In meinen Fall ist das MYSQL. Deswegen ist mir schwer zu sagen ob das mit MYSQL genauso schnell sein soll. Die Jetzige lösung ist das ich alle Dokumente in rootordner (dokumente) speichere. (jeder Ordner und Datei haben eine ID) Datensicherung Root Ordner (fertig

[shmia]

Vorteil Speicherung ausserhalb der Datenbank:
a.) die Dokumente können auch über einen Webserver zugänglich gemacht werden.
b.) die Dokumente könnte über eine Fulltext Search Engine durchsucht/indiziert werden

[Phoenix]

Zitat von shmia:

Vorteil Speicherung ausserhalb der Datenbank:
a.) die Dokumente können auch über einen Webserver zugänglich gemacht werden.
b.) die Dokumente könnte über eine Fulltext Search Engine durchsucht/indiziert werden

Hrm?

a.) geht auch (und ich würde sogar behaupten besser!) aus einer Datenbank. Grosse Filehoster packen die Dateien einfach aus Gründen der einfacheren Verwaltung immer nur in Datenbanken

b.) geht auch in der Datenbank. Okay, ist etwas aufwändiger und ich glaub nicht das MySQL das von Haus aus kann, aber ne Indizierung ist ohne weiteres möglich und auch ne Volltextsuche kann man auf sowas loslassen.

[hoika]

Hallo,

ein Problem bei "in der Datenbank" ist das Backup,
sofern die DB kein inkrementelles Backup erlaubt.
Die Backup-Dateien werden immer grösser,
es dauert immer länger.

Hat man ein dateibasierte Lösung (es werden nur die Pfade gespeichert),
ist es bei guter Vorplanung auch möglich,
alle Dateien eines Jahres zu sichern
und dann zu löschen.
Es muss dann nur eine entsprechende Meldung ausgegeben werden,
wenn sie gesichert ist ("Datei bitte zurückspielen" usw.)

Das normale Synchronhalten sollte kein Problem sein,
solange die Dateien nicht den Nutzern selber zugänglich sind.

Ein Bekannter hat mal eine Interbase6-DB (jaja es war nicht FB)
getestet, bei 2 GB Größe wurde es immer langsamer.

Jetzt nimmt der Oracle und hat keine Probleme mehr.

Es kommt immer darauf an.
Man sollte die DB einfach mal "füllen",
also z.B. alle Dateien der eigenen Platte rein
und dann ausprobieren, wie

1. die Queries laufen (select, edit, update)
2. das Backup aussieht.


Heiko

[alzaimar]

Neulich musste ich für einen Freund eine Bilddatenbank mit Access implementieren. Weil das mit WLAN funktionieren sollte, mussten wir die Dateien extern ablegen. Stattdessen wurde der Pfadname in Access abgelegt.

Klappte ganz gut.

Bis jemand das Bildverzeichnis gelöscht hat.

Beim nächsten mal war der Rechner, auf dem die Bilder abgelegt haben, weg (war auf einer Messe, ein Laptop)

Danach die Festplatte futsch.

Mein Fazit:

1. Besorg Dir eine DB, die das kann (was ihr alle an MySQL so toll findet, ist mir ein Rätsel)
2. Speichere die Dokumente in der DB.
3. Pack die DB auf einen Rechner, der den Namen 'Server' verdient.
4. Backup
5. Backup
6. Backup

@hoika: Ich weiss nicht, was Du für eine DB hast, aber ein inkrementelles Backup wird nicht immer größer, sondern sichert doch nur die Änderungen. Klar, ziwschendrin muss man immer eine Vollsicherung machen.

Ich würde heutzutagen nicht mehr das Argument "Speicher" anführen. Ich hab Jemanden, der hat einfach eine Wechselplatte als Sicherung

[mkinzler]

Zitat:

@hoika: Ich weiss nicht, was Du für eine DB hast, aber ein inkrementelles Backup wird nicht immer größer, sondern sichert doch nur die Änderungen. Klar, ziwschendrin muss man immer eine Vollsicherung machen.

Zitat von Hoika:

sofern die DB kein inkrementelles Backup erlaubt.

Im Zweifel kann man das ja selber implementieren.

[uwi1961]

@alzaimar

Zitat:

1. Besorg Dir eine DB, die das kann (was ihr alle an MySQL so toll findet, ist mir ein Rätsel)

Kann man in MySQL (5) in ein BLOB-Feld keine beliebigen Daten speichern

Zitat:

11.4.3. Die Spaltentypen BLOB und TEXT
Ein BLOB ist ein binäres großes Objekt, welches eine variable Menge von Daten aufnehmen kann. Die vier BLOB-Typen sind TINYBLOB, BLOB, MEDIUMBLOB und LONGBLOB. Sie unterscheiden sich lediglich in der maximalen Länge der Werte, die sie aufnehmen können.

Gruß Uwe