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:

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:

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:

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 :gruebel:

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

[Karstadt]

Morgen. Jetzt komme ich mit gegenargument:

Zitat:

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.

Dateien befinden Sich auf der Festplatte eines Servers im Netzwerk.

Ist die DB weg, sind ALLE daten weg (gelöscht, kaputt) sind alle Daten weg inc. Dokumente etc...

(Datensicherung zurückspielen heist Daten weg seit der letze Sicherung (Trifft auch in meinen Fall zu) aber in meinen Fall wird das nicht so häftig sein (denke ich )))


Bei eine Sicherung wird der root ordner gesichert und die MYSQL DB.

PS: was ist am Mysql DB so schlecht?

Nun denke ich das beide Lösungsansätze richtig sind. Ich meine es gibt immer mehrere Lösungen die zu einem Ziel führen...

[hoika]

Hallo,

ich meinte, wenn eine DB kein inkrementelles Backup kann (FB1.5),
dauert das lange.
Es lungern in der DB ja auch Bilder, die ein Admin schon längst
auf DVD gebrannt hätte, weil sie zu alt sind,
wenn er direkt drauf zugreifen könnte.

Es kommt halt immer auf den Fall an.

Zu dem "Bilderverzeichnis gelöscht".
Da gibt es für den Admin keine Entschuldigung.

Ich könnte ja auch sagen,
jemand hat aus Versehen Oracle abgeschossen
und die Datenbank-Dateien danach gelöscht.

Prinzipiell stimme ich aber zu, alles in einer DB zu halten,
nur muss man dann halt auch einige Sachen beachten (siehe die anderen Postings hier).


Heiko

[hsg]

Moin Moin,

es hat alles seine Vor- und Nachteile. Wir haben uns bei unserer Dokumentenverwaltung für die Datei-Basierte Lösung entschieden. Da sich die Dokumente auch noch ändern können, werden die vorhandenen Dateien umbenamt und in der Extension wird der Versionsstand mit angehangen. Vorteil: die alten Dokumente können noch eingesehen werden und damit die erfolgten Änderungen nachvollzogen werden. In der Datenbank müsstest du dafür einen neuen Datensatz anlegen und dementsprechend von vornherein deine Abfragen so aufbauen.

Bei uns kamen weitere Anforderungen hinzu, wie Dokumente über mehrere Standorte: Alle Dokumente sind an allen Standorten verfügbar, die Standorte selber sind untereinander mit Standleitungen verbunden. Damit wir durch die Replikationen der Datenbanken (hier im übrigen der Advantage Database Server) nicht die Standleitungen dichtmachen haben wir eine Cache-Lösung für die Dokumente implementiert, d.h. im Datensatz steht der für dieses Dokument verantwortliche Standort. Bei Anfragen eines anderen Standortes nach so einem Dokument wird erst geprüft, ob das Dokument im Cache des anfragenden Standortes liegt, wenn nicht, wird das Dokument vom verantwortlichen Standort abgeholt. Falls es bereits im Cache liegt, wird geprüft, ob der Stand noch aktuell ist, wenn ja: Dokument wird aus dem Cache geholt => kein Belastung der Standleitung, wenn nicht, wird es im Cache erneuert und dann von dort ausgeliefert.

Damit wird die Standleitung am wenigsten belastet.

Bezüglich der Sicherheit: die Dokumente liegen auf einem Server, kein Benutzer kommt an das Verzeichnis ran (außer natürlich der Administrator). Das Ausliefern der Dokumente übernimmt der Dokumentenserver über eine Socket-Verbindung.

Inkrementelle Backups sind dabei überhaupt kein Problem, die Dokumente sind auch noch nach kaputter Datenbank vorhanden und im Notfall findet man alles auch als normaler Mensch wieder.

Gruß
Jörg

[Karstadt]

Hallo.

So stellte ich mir das auch vor. Nach eine Datensicherung gehen die Daten (DB incl Dokumente) verloren. Der Admin ist in Urlaub. Nun werden die Daten DRINGEND gebraucht und die brauchen nur einen einzigen Ordner (Rechnungen). Da die komplete Rücksicherung ca. 1 Tag dauern wird (wenn die db Größe sehr gross sein wird) geht 1 Tag verloren. Bzw. Es werden alle Daten Rückgesichert, obwohl nur ein Ordner in diesen Fall gebraucht wird.

[mkinzler]

Zitat:

Da die komplete Rücksicherung ca. 1 Tag dauern wird (wenn die db Größe sehr gross sein wird) geht 1 Tag verloren. Bzw. Es werden alle Daten Rückgesichert, obwohl nur ein Ordner in diesen Fall gebraucht wird.

Sicherst du die DB auf Disketten :stupid:

[Karstadt]

Die Daten werden natürlich auf einen Externen Laufwerk gesichert. (ein Tag ist bestimmt übertrieben aber so ähnlich kann es ablaufen).

Nun ja beide Lösungen sind gut. (wenn diese funktionieren) ;)

[bernau]

Da will ich nun auch mal meinen Senf dazugeben :-)

Ich bevorzuge mittlerweile die Speicherung in eine DB (konkret ist es ADS). Du musst das Verzeichnis nicht für die Clients freigeben. Dies ist ein wesentlich besserer Schutz vor dem Datenklau. Man kann auf jedes Dokument einzelene Berechtigungen vergeben und nur die gewünschte Client-Software kann mit den Daten was anfangen.

Aber letztendlich ist es immer eine Geschmacksache.


Gerd

[hsg]

Zitat:

Zitat von bernau

Da will ich nun auch mal meinen Senf dazugeben :-)

Ich bevorzuge mittlerweile die Speicherung in eine DB (konkret ist es ADS). Du musst das Verzeichnis nicht für die Clients freigeben. Dies ist ein wesentlich besserer Schutz vor dem Datenklau. Man kann auf jedes Dokument einzelene Berechtigungen vergeben und nur die gewünschte Client-Software kann mit den Daten was anfangen.

Aber letztendlich ist es immer eine Geschmacksache.


Gerd

Wie bereits gesagt: das kannst du auch in einer Datei-Basierten Lösung (an mein Dokumentenverzeichniss kommt nur ein Admin ran!) machen.
Einen Vorteil der Datei-Basierten Lösung habe ich noch vergessen: in den Dateien kann so wunderschön Streams verstecken :lol:
Soll eine Datei bearbeitet werden schreibe ich die für mich wichtigen Information in einem Stream in der Datei und beim hochladen kann ich gleich diese Informationen vorher auslesen und damit sorgen, dass die Datei wieder an die Richtige Stelle kommt.

OT:
Aber nett zu sehen, dass noch mehr Leute den ADS nutzen :-D

[bernau]

Zitat:

Zitat von hsg

Wie bereits gesagt: das kannst du auch in einer Datei-Basierten Lösung (an mein Dokumentenverzeichniss kommt nur ein Admin ran!) machen.

Das must du mir erklären. Wenn ein Dokumentenverzeichnis nur für den Admin sichtbar ist, wie kommen die Clients, die ja keine Administratorrechte haben, an die Daten?

Zitat:

Zitat von hsg

Einen Vorteil der Datei-Basierten Lösung habe ich noch vergessen: in den Dateien kann so wunderschön Streams verstecken :lol:
Soll eine Datei bearbeitet werden schreibe ich die für mich wichtigen Information in einem Stream in der Datei und beim hochladen kann ich gleich diese Informationen vorher auslesen und damit sorgen, dass die Datei wieder an die Richtige Stelle kommt.

Streams funktionieren wunderbar mit ADS. Alles was ich habe wird in Streams gepackt und in die Datenbank geschrieben. Wenn kein externes Programm auf die Daten zugreiffen muss ist es somit noch nicht einmal notwendig die Daten auf die Platte zu schreiben/cachen. (Sei es nun Bilder, RFT-Texte, Tonaufzeichnungen etc.)

Zitat:

Zitat von hsg

OT:
Aber nett zu sehen, dass noch mehr Leute den ADS nutzen :-D

Das sind mehr als du denkst. Ich bin auch immer wieder verwundert wie viele ADS kennen. Liegt vieleicht daran, daß es in der Local-Version kostenlose ist kein grossen overhead hat.


Gerd

[Hansa]

Eine solche Entscheidung würde ich lediglich an folgender Frage festmachen : ändern sich die Dokumente fortlaufend an allen Ecken und Kanten oder nicht ? Muß ich also immer die komplette DB sichern oder nur Teile ? Nun kann ich mir schwerlich vorstellen, daß ein bereits verschickter Brief anschließend noch jeden Tag 5mal geändert wird. Es handelt sich zudem anscheinend um ein MySQL-Großprojekt im Terabyte-Bereich. :stupid: Was wäre im Fall der Fälle, die DB muß zurückgesichert werden ? Wer kann das überhaupt alles so installieren, daß man schnellstmöglich an die Daten wieder drankommt ?

Datenklau, Sabotage usw. ? Bestet Mittel ist immer noch Format C: und dann dürfte es egal sein was jetzt wie ist. Was wäre in folgendem Fall besser : versehentlich wird ein wichtiges Dokument gelöscht. Die Sicherung befindet sich auf 5 CDs. Bei gutdurchdachter Organisation mit Dateien könnte man wissen, die Datei ist auf CD 3. Ruckzuck wäre sie wieder da. Und bei DB ??? 8) Man könnte das auch im Falle von Festplatten-Crashs einfach auf anderen Rechner kopieren und fertig.

[hsg]

Zitat:

Zitat von bernau

Das must du mir erklären. Wenn ein Dokumentenverzeichnis nur für den Admin sichtbar ist, wie kommen die Clients, die ja keine Administratorrechte haben, an die Daten?

Ich habe auf dem Server einen Dienst laufen, der mein "Dokumentenserver" ist, alle Clients stellen ihre Anfragen über TCP/IP an diesen Dienst. Der verschickt die entsprechenden Antworten und auch die Dokumente.

Zitat:

Zitat von bernau

Streams funktionieren wunderbar mit ADS. Alles was ich habe wird in Streams gepackt und in die Datenbank geschrieben. Wenn kein externes Programm auf die Daten zugreiffen muss ist es somit noch nicht einmal notwendig die Daten auf die Platte zu schreiben/cachen. (Sei es nun Bilder, RFT-Texte, Tonaufzeichnungen etc.)

Ich spreche hier von NTFS.Streams, also "Dateien in Dateien". Unsere Dokumente leben: es sind nicht nur Briefe, sondern komplette Montageanweisungen, Konstruktionszeichnungen etc. die damit gehandelt werden müssen und über unser PPS-System in den entsprechenden Abschnitten zur Verfügung stehen müssen (z.B. die Konstruktionszeichnung muss beim Artikel und in der Auftragsverwaltung abrufbar sein). Diese Dokumente werden logischerweise von der Konstruktionsabteilung immer entsprechend angepasst => also wird die Zeichnung zur Bearbeitung aus der Dokumentenverwaltung abgezogen und evtl Tage später erst wieder hochgeschoben. Daher speichere ich die wichtigen Information in der Datei selber noch einmal und komme so über DateiName.Ext::StreamName wieder ran. Beim Hochladen kann ich diese Informationen wieder auslesen und im entsprechenden Dialog die Werte bereits korrekt eintragen.

OT:

Zitat:

Zitat von bernau

Das sind mehr als du denkst. Ich bin auch immer wieder verwundert wie viele ADS kennen. Liegt vieleicht daran, daß es in der Local-Version kostenlose ist kein grossen overhead hat.
Gerd

Der Hauptgrund dürfte wohl eher daran liegen, dass viele alte Clipper- und DBase-Programme und -Programmierer bei der Umstellung auf Windows nicht gerne das Datenbank-System umstellen wollten. Leider sterben die VisualObjects-Programmierer wohl langsam aus, gerade dort war der ADS mit die beliebteste Client-Server Datenbank.

Gruß
Jörg

[Catbytes]

Zitat:

Zitat von hoika

Zu dem "Bilderverzeichnis gelöscht".
Da gibt es für den Admin keine Entschuldigung.

Warum?

[winnionkel]

Ich wollte nur anmerken, wenn ihr ein kommerzielles Dokumentenmanagment System erstellt, MÜSSEN die Dokumente in der DB gespeichert werden. Es gibt darüber Vorschriften.
z.B.: wenn ihr das einem Anwalt verkauft.

Die Dokumente habe ich z.B. in einer eigenen Tabelle gespeichert. Die hat nur zwei Felder, ID und Blob.
Somit ist auch die Datensicherung sehr einfach.
Gruß winni