Dateien in Datenbank statt Fileserver ??

verwendetes Datenbanksystem: MySQL

Kurze Vorgeschichte:
ich suche gerade ein Open source Dokumentenmanagement System.
In der engeren Auswahl waren: Alfresco, Knowledgetree, Xinco und Agorum core.

Letzteres finde ich für den Zweck für den ich es brauche am passensten.

Jetzt mein Problem / Frage:
Agorum Core emuliert über Netbios eine Art Netzlaufwerk (wie ein Fileserver)
allerdings werden alle Daten / Dateien in einer MySQL 4 Datenbank gespeichert.
D.h. die dort abgespeicherten Dateien sind nur in der Datenbank vorhanden nicht im Dateisystem.

Was haltet Ihr davon? zumal mal nicht sehr oft positives darüber hört wenn leute BLOBs in einer DB speichern.
Aber die Entwickler müssen sich ja was dabei dedacht haben oder?

Leute die pauschal BLOBS verteufeln, und partout Files im dateisystem
ablegen wollen, sind meist nicht auf der höhe der Zeit.

Der MSSqlServer 2008 hat dafür sogar extra einen neuen Datentyp,
weil diese herangehensweise in einer verteilten Welt immer mehr Sinn macht.

Ist die Datei im Dateisystem, kann sie z.b. von irgendeinem Dappes gelöscht
werden, dann ist sie weg.
Auch kann durch falsche Pfade, Umräumaktionen usw viel schaden angerichtet werden, wenn nur die Pfade verwaltet werden.

Ist sie in der DB kann jeder drauf zugreifen, und das Backup ist auch sehr einfach möglich.

wow, hatte nicht mit einem positiv ausfallendem kommentar gerechnet.
Ich sehe natürlich auch die Vorteile die das bringen könnte, bin aber natürlich genauso an den Nachteilen interessiert, erstmal vielen Dank für deine Meinung.

Der Nachteil ist nur dass die Datenbank viel größer wird.

Das stört MySQL aber recht wenig 😉

Grüße Bernd

@BerndFfm: Mit die Datenbank wird größer meinst du größer als gleicher inhalt auf einem Fileserver?

@BerndFfm: Mit die Datenbank wird größer meinst du größer als gleicher inhalt auf einem Fileserver?

Ich mag jetzt mal behaupten, ja! Wenn ich bei uns Datenbank von 600MB sehe mit reinen Text und die komprimieren kann mit ZIP oder RAR auf unter 100 MB dann denke ich das auch Dateien als BLOB mehr Platz wegnehmen als wenn ich sie zB. als PDF auf die Festplatte lege.

Ich stehe vor einem ähnlichen Problem und habe mich auch entschieden Dokumente in der DB abzulegen. In meinem Fall handelt es sich um PDF Dateien mit einer jeweiligen Größe von etwa 1 MB. Werden wohl bis zu 300 000 Dateien werden im schlimmsten Fall. Bin mal gespannt wie sich das auf die Datenbank auswirken wird.

Gruß
Robert

@roeb, welche DB benutzt du dazu?

zur info zunächst werden es bei mir nur ca 3000 Dateien mit einer Durchschnittsgröße von 0,7MB sein.

Bei MySQL gibt es leider nicht wie im SQL-Server den Datentyp Stream sondern du kannst die Sachen nur als BLOB ablegen.

Die Frage ob nun BLOB oder FileSystem hängt von mehreren Faktoren ab und Geschwindigkeit sowie Auslastung müsste entsprechend getestet werden.*Wieviele Dateien sind es die gespeichert werden? *Wie groß ist eine Datei im Schnitt? *Welches FileSystem verwendest du? *Was für Hardware verwendest du (Festplatten, RAID)?

Bei 300.000 Dateien beispielsweise würde ich die Daten ungern in eine Tabelle ablegen sondern diese nur als Verweis in einem Verzeichnis ablegen. Hier hast du aber wiederum das Problem, dass du ein stabiles und performantes FileSystem brauchst.

Nochmal generell zu den Vor- und Nachteilen:

Das Hauptargument dagegen ist halt daß die Datenbank dadurch um ein Vielfaches größer wird als wenn man die Dateien irgendwo als Dateien auf dem Server hat und in der DB nur den Pfad speichert.
Die Gegner sagen meistens: die DB ist viel größer, dadurch viel langsamer usw.

Andersherum ist es für den Admin aber viel leichter zu handeln wenn die Dateien in der DB gespeichert sind. Nicht nur weil man sie nicht einfach aus dem Filesystem löschen kann, auch für Datensicherung etc. ist ein Backup der Datenbank einfach besser zu handhaben als ein Backup der DB plus ein Backup vom Ordner mit den Dateien.

Wie FZelle schon geschrieben hat, hat der SQL Server 2008 den Datentyp FILESYSTEM der das beste aus beiden Welten vereint: die Dateien sind tatsächlich im Filesystem und nicht in der DB, aber die ganze Verwaltung übernimmt der SQL Server, d.h. nach außen hin arbeitet man damit als wären sie in der DB.

Aber auch wenn man den SQL Server 2008 noch nicht einsetzt kann man gut damit arbeiten.
Ich hatte es hier schonmal geschrieben - wir setzen ein selbstgeschriebenes Dokumentenmanagementsystem auf SQL Server 2005 ein. Die Tabelle mit den Dokumenten ist inzwischen 282 GB groß und enthält 2,1 Mio. Datensätze, aber wenn man die Datenbank richtig designt gibt es auch damit keine nennenswerten Geschwindigkeitsprobleme (steht auch in dem verlinkten Posting).

ich möchte nicht den bestehenden Fileserver ersetzten.
Was ich möchte ist: Die dateien für die ich die features eines DMS benötige
(Arbeitsanweisungen, Formblätter usw.) in die Datenbank auslagern weil ich über den Fileserver keine automatische versionierung, historienerhaltung, volltextsuche usw. habe. Alle "normalen Dateien" für die diese Features nicht benötigt werden können auf dem bestehenden NTFS fileserver bleiben.
Ach ja als Alternative zu MySQL4 wäre PostgreSQL möglich.

@roeb, welche DB benutzt du dazu?

SQL Server 2005 Enterprise wird es wohl wegen der Datenmenge werden, da Express mit 4GB wohl ein wenig zu klein ist. 🙂

Ich habe folgende Gründe die Dateien trotz größerer Datenbank in der DB abzulegen:

• Eindeutige Zuordnung ist möglich. Wenn man eine Datei umbenennt ist sie nicht mehr zuordbar.
• Benutzer / Admin kann die Dateien nicht einfach löschen. Bzw. nur mit Aufwand und Fachwissen.
• Dateien können nicht ohne weiteres bearbeitet oder ausgetauscht werden.

Bei mir handelt es sich um sehr wichtige und rechtliche Dokumente wo Mitarbeiter des Kunden eine Unterschrift leisten nachdem sie z.B. in ein Gerät eingewiesen wurden. Die Papiere werden als PDF gescannt und in der DB gesichert. Der Kunde sichert sich somit rechtlich ab. Sollte es einen Mitarbeiter irgendwie möglich sein an die Datei zu kommen, so könnte das unter Umständen Folgen haben. Da hab ich kein Problem mit mehr Speicherbedarf.

Gruß
Robert

Zwar nicht Open-Source aber dennoch ein ziemlich gutes Dokumentenverwaltungstool sind die SharePoint Services (Die Services sind kostenlos). Da hat man eine Historie/Versionierung aller Dokumente, Benutzerrechte, Vorlagen, usw...

Ist auf jeden Fall ein Blick wert.

Das ganze Ding setzt allerdings auf einen SQL Server auf.

Zwar nicht Open-Source aber dennoch ein ziemlich gutes Dokumentenverwaltungstool sind die SharePoint Services (Die Services sind kostenlos). Da hat man eine Historie/Versionierung aller Dokumente, Benutzerrechte, Vorlagen, usw...

Das ist eine Idee an die ich noch garnicht gedacht habe. Werd ich auch mal in Erwägung ziehen 🙂

Danke für den Tip Khalid, aber ich glaube bei SharePoint hat man kein Netbios Netzlaufwerk.

Ja, das ist richtig.

Aber wozu brauchst du das genau?

ich möchte ohne mehraufwand einen größeren Nutzen.
D.h. wenn ich ein emuliertes netzlaufwerk habe ändert sich für die nutzer
gar nichts sie arbeiten genau wie bisher im explorer offnen ändern und speichern Dateien.
Sie brauchen sich nicht mit neuen oberflächen auseinanderzusetzten sie brauchen nicht ein- oder auschecken sie kriegen es nicht einmal mit das sich irgendetwas geändert hat.
Trotzdem habe ich automatisch alle Dateien in der DB und versionierung, volltextsuche und alle anderen features eines DMS.

OK, das geht mit SharePoint wirklich nicht 🙂

Ziehe die Aussage zurück. SharePoint kann es von Haus aus nicht, aber es gibt wohl Zusatzprodukte, die das können: Hier

danke für die Info, aber auch dort sehe ich im kontextmenü schon wieder einchecken / auschecken usw.
Für meine bescheidenen Zwecke ist denke ich die kostenlose Variante für die ich keine Zusatzmodule brauche die bessere Variante.
Ich denke zumindest das ich es auf einen Versuch ankommen lassen werde.