PDF-Dokumente in eine Datenbank oder nicht

[RWarnecke]

Hallo Leutz,

ich plane gerade die Umsetzung einer Dokumentenverwaltung. In dieser Verwaltung sollen hauptsächlich nur PDF-Dokumente rein. Jetzt ist meine Überlegung, packe ich die ganzen Dokumente in die Datenbank oder mache ich ein Verzeichnis, wo alle Dokumente drin gespeichert werden und in der Datenbank nur eine Referenz steht zur Datei. Bei der Variante mit dem Verzeichnis ist auf jedenfall sichergestellt, dass keiner der Benutzer im Verzeichnis Änderungen durchführen kann. Hier kann lediglich nur das Programm schreiben.

Was habt Ihr für Erfahrungen gemacht, mit der Speicherung der PDF-Dokumente in der Datenbank und mit der Speicherung in einem Verzeichnis und einer Referenz in der Datenbank ?

Mir geht es hier in diesem Beitrag lediglich nur um Erfahrungen. Ich möchte wissen, wo die Grenzen sind, wo Komplikationen auftauchen können. Bei welchem Datenbanksystem habe ich bei den Varianten vielleicht die meisten Probleme ?

Schreibt mir eure Erfahrungen, gerne auch bestimmte Hardwarekonfigurationen wo bei euch eine der beiden Varianten schon besonders lange und gut läuft.

[sh17]

Würdest Du die Dateinamen im Falle der Verzeichnisvariante selbst bestimmen? Beim Verzeichnis ist auf jeden Fall die maximale Zahl der Dateien zu beachten.

[vagtler]

Schon einmal über den Einsatz einer NoSQL-Datenbank für diesen Use Case nachgedacht?

[Dejan Vu]

Entweder du packst die Dateien in die Datenbank, oder nur Dateinamen (dann muss natürlich der Pfad zu den Dateien publik sein). Beides hat Vor- und Nachteile.

Datei in DB
Vorteile: Alles in einer DB, beim Backup/Restore keine Probleme. Vollständige Kontrolle über die Dateien.
Nachteile: Backup wird sehr groß (logisch)

Nur Namen in der DB
Vorteile: Kleine Backups, Dateien können direkt angeschaut und verändert werden.
Nachteile: Daten können direkt verändert, gelöscht, umbenannt usw. werden. Fehlende Sicherheit

SQL-Server (ab Version 2012) bietet die FileTables, was eine Kombination von beidem ist. Gearbeitet habe ich damit bisher noch nicht. Ich habe bisher PDF als normalen BLOB behandelt und konnte die ohne merkliche Verzögerung laden und anzeigen. Da das System auf wenige 1000 Dateien beschränkt war, und das Backup eh >20GB ist, war mir das ziemlich egal.

[mm1256]

Hallo,

ich mach's seit etwa 6 Jahren mit Speicherung in der Datenbank, wobei zwar überwiegend PDF's gespeichert werden, aber auch Grafiken, Word-Dokumente usw.

Vorteile der Datenbank-Variante:

- Datensicherung: Tabelle(n) sichern und alles ist gesichert. Es kann prinzipiell nichts "vergessen werden"
- Einfacher Datenumzug: Besonders bei den vielen XP-Umzügen in den letzten 2 Jahren war das von Vorteil
- Kein Zusatzaufwand für die Zuteilung bzw. Vergabe von Zugriffsrechten

Nachteile:

- Wenn die Tabellen über 4 GB anwachsen wird die Datenbankpflege (z.B. Index-Neuaufbau) zeitaufwändig. Darum habe ich die Archive jetzt nach einzelnen Jahren aufteilen müssen. Doch diesen Nachteil muss man wohl langfristig auch bei Verzeichnissen wegen der Anzahl der Dateien hinnehmen.

BTW ich verwende NexusDB mit nativem Zugriff, also ohne SQL. Das ist von Haus aus schon sehr schnell. Wie sich andere DB's in diesen Dateigrößen verhalten, möchte ich mangels eigener Erfahrung nich viel dazu sagen. Ein Bekannter macht es mit MySQL. Er wird jetzt wohl auf externe Dateien umstellen.

Insgesamt gesehen bereue ich es nicht, die DB-Variante gewählt zu haben.

[sh17]

PDF etc ist ja alles kein Problem.

Wo ich noch ein Problem hätte, wären änderbare Dateien (Word, Excel oder was auch immer).

Wie soll man die vernünftig dem Benutzer zu Bearbeitung anbieten? Der hat sich da einen virtuellen Verzeichnisbaum zu seinem Vorgang zusammengeklickt und möchten den Inhalt natürlich auch on the fly bearbeiten. Ich hatte schon mal an virtuelle Dateisystemtreiber gedacht, die das ganze nach hinten in die DB mappen. Aber da wollte ich nix zukaufen, was selbst gestricktes wäre gut. z.B. Dokanx

[mkinzler]

Da Word und Co. nicht von/in Streams Lade/speichern kann, müsste man den Weg über CheckOut/CheckIn gehen, d.h temporäres Auslagern und Wiederzurückschreiben nach Bearbeitung.

[mm1256]

Zitat:

Zitat von sh17 (Beitrag 1287194)

Wie soll man die vernünftig dem Benutzer zu Bearbeitung anbieten?

Ich denke, die Bearbeitung ist nicht das Problem, es soll ja archiviert werden:

Zitat:

Zitat von RWarnecke

Bei der Variante mit dem Verzeichnis ist auf jedenfall sichergestellt, dass keiner der Benutzer im Verzeichnis Änderungen durchführen kann. Hier kann lediglich nur das Programm schreiben.

[sh17]

Zitat:

Zitat von mkinzler (Beitrag 1287195)

Da Word und Co. nicht von/in Streams Lade/speichern kann, müsste man den Weg über CheckOut/CheckIn gehen, d.h temporäres Auslagern und Wiederzurückschreiben nach Bearbeitung.

Das ist für den Anwender aber nicht transparent. Entweder er muss sagen, "so, jetzt bin ich fertig" oder das Programm versucht zu erkennen, wann eine Datei nicht mehr benutzt wird. Alles zu windig. Noch schlimmer wird es, wenn das jeweilige Anwendungsprogramm neben der gewünschten Datei weitere Dateien nachlädt.

[sh17]

Zitat:

Zitat von mm1256 (Beitrag 1287196)

Ich denke, die Bearbeitung ist nicht das Problem, es soll ja archiviert werden:

OK, ich möchte jetzt nicht den Thread kapern.

[Lemmy]

Zitat:

Zitat von vagtler (Beitrag 1287188)

Schon einmal über den Einsatz einer NoSQL-Datenbank für diesen Use Case nachgedacht?

ot:
was wäre denn in diesem speziellen Fall der Vorteil?

[mkinzler]

Zitat:

Zitat von sh17 (Beitrag 1287197)

Zitat:

Zitat von mkinzler (Beitrag 1287195)

Da Word und Co. nicht von/in Streams Lade/speichern kann, müsste man den Weg über CheckOut/CheckIn gehen, d.h temporäres Auslagern und Wiederzurückschreiben nach Bearbeitung.

Das ist für den Anwender aber nicht transparent. Entweder er muss sagen, "so, jetzt bin ich fertig" oder das Programm versucht zu erkennen, wann eine Datei nicht mehr benutzt wird. Alles zu windig. Noch schlimmer wird es, wenn das jeweilige Anwendungsprogramm neben der gewünschten Datei weitere Dateien nachlädt.

Es gibt aber einige DMS Systeme, die genau so funktionieren. Das funktioniert am Besten mit einem plugIn, welcher sich in den Speichervorgang, bzw. Dokumentschliessenvorgang einklinkt.

[RWarnecke]

Hallo,

danke erstmal für die vielen Antworten. Ich möchte in der Dokumentenverwaltung erstmal hauptsächlich PDF-Dokumente archivieren. Also keine Bearbeitungsfunktionen. Die Dokumente sollen lediglich nur aufgerufen werden können zum Ausdrucken oder zum Lesen in einer entsprechenden Anzeige. Nun aber zu euren Fragen und Antworten :

Zitat:

Zitat von sh17 (Beitrag 1287187)

Würdest Du die Dateinamen im Falle der Verzeichnisvariante selbst bestimmen?

Ja, die Dateinamen werden selbst bestimmt, wenn ich diese Variante nehmen sollte.

Zitat:

Zitat von sh17 (Beitrag 1287187)

Beim Verzeichnis ist auf jeden Fall die maximale Zahl der Dateien zu beachten.

Ich habe noch nicht gewusst, dass es hier eine Begrenzung gibt. Ich weiß zwar, dass ab einer bestimmten Verzeichnistiefe es Probleme gibt, von wegen Länge des Pfades aber bei der Anzahl. :gruebel::gruebel:

Zitat:

Zitat von vagtler (Beitrag 1287188)

Schon einmal über den Einsatz einer NoSQL-Datenbank für diesen Use Case nachgedacht?

Wie funktioniert die und was soll mir diese Datenbank bringen ?

Zitat:

Zitat von Dejan Vu (Beitrag 1287189)

SQL-Server (ab Version 2012) bietet die FileTables, was eine Kombination von beidem ist.

Das hört sich zumindest mal interessant an. Da werde ich mal ein wenig nach recherchieren.

Also, im Moment geht meine Tendenz in richtig Verzeichnis, da ich hier eine Dokumentenverwaltung am besten Abbilden kann und auf etwaige Änderungen besser reagieren kann. Das mit der Sicherung wäre hier kein Problem, da schon eine komplette Sicherung für Dateien existiert, die schon seit mehreren Jahren läuft. Hier müsste man nur noch das Verzeichnis mit hinzufügen, wo die Dokumente gespeichert werden.

Das ist erstmal lediglich nur eine Tendenz. Ich bin aber immer noch offen für weitere Erfahrungsberichte.

[mkinzler]

Zitat:

Also, im Moment geht meine Tendenz in richtig Verzeichnis, da ich hier eine Dokumentenverwaltung am besten Abbilden kann und auf etwaige Änderungen besser reagieren kann.

Da würde ich gerade das Problem bei den Verzeichnissen sehen. Eine "virtuelle" Verzeichnisstruktur in der datenbank ist imho viel flexibler und auch das "Verschieben" ist viel einfacher, man könnte Dokumente auch ohne größeres Wachstum Duplizieren und platzsparend Versionieren.

[sh17]

also rein Dateisystemtechnisch gibt es keine Beschränkung mit der Dateianzahl, allerdings geht der Windows Explorer ab ca 20000 Dateien in die Knie, so meine Erfahrung

//Edit
Maximum 4,294,967,295 :)

[RWarnecke]

Zitat:

Zitat von mkinzler (Beitrag 1287203)

Eine "virtuelle" Verzeichnisstruktur in der datenbank ist imho viel flexibler und auch das "Verschieben" ist viel einfacher, man könnte Dokumente auch ohne größeres Wachstum Duplizieren und platzsparend Versionieren.

Könntest Du das bitte näher ausführen, was Du damit meinst. Ich kann mir da nichts drunter vorstellen.

Zitat:

Zitat von sh17 (Beitrag 1287204)

also rein Dateisystemtechnisch gibt es keine Beschränkung mit der Dateianzahl, allerdings geht der Windows Explorer ab ca 20000 Dateien in die Knie, so meine Erfahrung

Wer arbeitet denn heute noch mir dem Explorer unter Windows ? Ich nicht mehr.

Zitat:

Zitat von sh17 (Beitrag 1287204)

Maximum 4,294,967,295 :)

Wow, ob man diese Anzahl Dateien jemals in einem Verzeichnis erreicht ? Ich glaube da ist genügend Luft nach oben da, wenn ich mal von meinen sehr grob geschätzten Werten ausgehe, die derzeit in einem 6stelligen Bereich angesiedelt sind.

[mkinzler]

Zitat:

Könntest Du das bitte näher ausführen, was Du damit meinst. Ich kann mir da nichts drunter vorstellen.

Die Dateien werden einfach in einem Datentopf(Tabelle) gespeichert.
Zusätzlich wird/werden der/die Verzeichnisba(ä)um(e) verwaltet. Durch einen weiteren Eintrag kann man dann den Ort der Datei im Verzeichnisbaum festlegen. Soll eine Datei in mehreren Verzeichnis vorkommen, genügen meherer Zuodnungseinträge auf die selbe Datei, so dass der Speicherbedarf nicht ansteigt. Bei Austausch der Datei werden alle Doubletten getausch( so kann keine Vergessen werden). Verschieben ist dann nur die Änderung des Zuornungsdatensatzes.

[Sir Rufo]

Das Allerwichtigste:

Schreibe deine Anwendung so, dass es egal ist, von wo du die Dateien bekommst!

Delphi-Quellcode:

IDocumentRepository = interface
  procedure Find( DocumentId : TDocumentId; out ADocument : TDocument );
  procedure Store( DocumentId : TDocumentId; ADocument : TDocument );
end;

Egal wie du dich jetzt entscheidest, tauchen in der Zukunft Probleme auf, dann baust du den konkreten Zugriff einfach um. Die Anwendung selber ändert sich nicht.

Um sicher zu gehen, kannst du dir zu diesem Interface auch einen Stresstest bauen und die unterschiedlichen Implementierungen prüfen. Selbst ein Mix ist denkbar (kleine Dateien in der Datenbank, große auf der Platte oder auf mehreren Platten, oder, oder, oder). Aber alles ist für die Anwendung versteckt in einem Interface.

[mensch72]

Bei einem lokalem System ist es eigentlich egal ob (SQL)DB oder Verzeichnisstruktur mit Dateien. Manueller Zugriff ohne Software scheidet bei erzeugten Dateinamen als "X1234567-987642-000.pdf" eh aus.

Zufällig habe ich vor 3Jahren eine ähnliche Lösung für einen Kleinbetrieb entwickelt. Der wollte einen 2. Betriebsteil eröffnen und Stand vor dem Problem, das alle Unterlagen im Archiv ja nur 1x da sind, aber dann an mehreren Orten gebraucht werden... Lösung: ALLE Leitz-Ordner incl. uralter A0-CAD-Plots mit vielen handschriftlichen Bemerkungen Blatt für Blatt scannen! (guter Kamera Tischscanner + Scanservice für die Plots)

Weil im Netzwerkzugriff jegliche Dateilösung mit Rechten und Freigabeverzeichnissen ein Krampf ist, der spätestens bei reiner IP Kopplung per (Internet)Fernzugriff zum Scheitern verurteilt wäre, habe ich mich damals für einen kleinen eigenen APP-Server auf IP-Basis entschieden. Der arbeitete damals zum Start intern(lokal) mit MS-SQL2008 und/oder auf Filebasis. Die "Clients" greifen also per "eigenem" TCP/IP-Socket Protokoll auf diesen APP Server zu. Das funktioniert sowohl lokal, als auch per Remotenetzwerkzugriff in akzeptabler Geschwindigkeit.

Nach und nach kamen dann Client seitig "fast unbemerkt" auf APP Server Seite im Laufe der Zeit einige Funktionen hinzu:
- 2 oder mehr APP Server können sich synchronisieren, heißt jeder Standort hat lokal jetzt "seinen" AppServer und es gibt noch ein dezentrales Backupsystem in einem Rechenzentrum
- CacheOnDemand, also möglichst Remote nur IndexSync, erst bei RemoteClient-Zugiff werden die Anzeigedaten auf die Remoteseite geholt und liegen ab dann dort direkt vor
- zusätzliche WebService Funktionalität
- wegen "Handling" fahre ich mittlerweile ausschließlich ein Multi-FileDB Konzept, heißt in der zentralen IndexTabelle, steht nicht der "DatenFileLink" sondern der "DatenDB-File-Connection-Link", sodass ich nie Datenbankfiles über 2GB Größe bekomme. Da der APP Server diesen Mechanismus 100% transparent versteckt und der gepoolte Connect/Disconnect der einzelnen DB-Files schnell genug geht, ist das eine Lösung, welche mit überschaubarer Dateianzahl bei fast voller Datenbank SQL Funktionalität eine quasi unbegrenzte Datenmenge auch über mehrere Festplattengrenzen hinweg managen kann.

Die Clients bekamen im Lauf der Zeit im Prinzip nur immer weiter verbesserte (Index) Suchfunktionen, welche daraus resultierten, das ich immer bessere OCR Tools regelmäßig als Batchprozess im APP Server über den Datenbestand laufen lasse, welche aus den (Bild)Dokumenten vollautomatisch so gezielt wie möglich Textinformationen zur Schlagwortsuche erfassen. Die (Hand)schrifterkennung hat sich da in den letzten Jahren sehr verbessert.


Bleibt wie immer die Frage: lohnt der Aufwand sowas selbst zu machen... ich hatte den Vorteil, das "nur" Funktionalität gefordert war. Interner Datenschutz über zig Zugriffsrechte musste nicht sein. Backup simpel als DB Backup.

[IBExpert]

von unserer Seite aus mit Dateien, insbesondere PDF als auch Images, haben wir als auch diverse Kunden sehr gute Erfahrungen gemacht.
Beispielsweise nutzt ein Kunde eine Firebird DB mit mittlerweile mehr als einem Terabyte an pdf Dokumenten. Bei unseren Kundenprojekten sind das meistens aber 50 bis 100 GB.

Wir nutzen gescannte pdfs schon seit mehr als 10 Jahren, um die in eine Firebird DB zu packen und haben ein kleines viewer programm da drauf, mit dem man im extrahierten Text in einer zweiten Blobtabelle mit fk auf den PDF in der PDFBlob Tabelle eine Volltextsuche machen kann.

Meine persönlichen Erfahrungen mit NTFS Filesystemen unter Windows haben mir gezeigt, das die nun mal nicht für große Anzahl von Einzeldateien geeignet sind. Durch ein Programm, das eine große Menge kleiner Dateien im filesystem in einem Pfad erzeugt hatte, habe ich festgestellt, das die mittlerweile ca. 2mio dateien das filesystem nahezu unbenutzbar gemacht haben. Der Eplorer war dabei schon lange nicht mehr benutzbar, aber auch ein simples DOS Fenster, das einen dir Befehl in dem Pfad ausführen sollte, hab ich nach mehreren Minuten abgebrochen. Angeblich soll das mit 4mrd dateien pro ordner gehen, das halte ich aber für ein Gerücht. Ich hab nachher die Platte formatiert, nachdem ich mehrere Stunden versuchte, die Ordnerinhalte zu löschen.

Zurück zur Ausgangsfrage: Warum also pdfs lieber in der DB (mit Fokus auf Firebird)?

1. Trigger: Wenn jemand was löscht kann ich das trotzdem Programmgesteuert in dieser db oder auch in einer anderen DB speichern und archivieren

2. Datensicherung: Firebird hat ein Hot Backup Verfahren, d.h. obwohl dutzende User vielelicht gerade irgendwas lesen und/oder schreiben, kannst du die Daten sichern und es werden nicht wie bei Dateikopien offene Dateien einfach ignoriert. Bei Bedarf kannst du mit einer Datei auf deinem Laptop oder einer Wechselplatte alle PDF Dateien mitnehmen.

3. Archivierung: Wenn eine Datenbank ziemlich groß wird, ist natürlich ein Vollbackup aufwändig. Wir arbeiten daher immer mit den Dateien in zwei Datenbanken. In der Produktionsdatenbank, die meistens auf einer SSD liegt, werden alle neuen PDFs eingefügt. Bei uns wird aber ein mal monatlich ein großer Teil der Dateien (die die 30 Tage oder älter sind), in eine zweit DB übertragen. Diese ist normalerweise Read Only und wird nur während der Übertragung der Daten zeitweise auf Readwrite gestellt. Während der Übertragung liest eine SP die PDF und Bildinhalte in der Tabelle der Produktions DB au, überträgt die per ... execute statement on external ... an die Archiv DB, wo mit gleichem PK die Inhalte in eine strukturgleiche Tabelle eingetragen werden. Anschliessend wird der Blobinhalt in der Produktions DB auf NULL gesetzt. Das das ganze unter Transaktionskontrolle läuft, geht garantiert nicht verloren, das geht per Firebird direkt von db zu db. Nach der Übertragung wird dann die Archiv DB wieder auf Readonly gesetzt. Wenn ich nun ein Backup der Archiv DB mache, brauch ich den Rest des Monats kein weiteres Backup machen, kann sich ja nichts geändert haben, ist ja Readonly. Für das Auslesen der DB nutze ich eine SP, die einfach die Blobs aus der Produktions DB zu einem PK ausliest und wenn die dort nichts gefunden hat, dann sucht die eben per execute statement on external auf der Archiv DB.
Ob man die Archivierung nun monatlich macht oder wöchentlich, oder jedes Jahr eine weitere Archiv DB anlegt, ist aus der Sicht der Applikation egal, da diese immer über den Umweg der SP Blobs holt. Die Archiv DB liegt dann auch durchaus auf einer normalen Festplatte, weil der Speed beim Auslesen einzelner Blobs nun wirklich keine Zauberei ist und die Blobs ja auch immer nur dann geholt werden, wenn irgendjemand die ansehen will. Überschreiben alter Blobinhalte mache ich generell nicht, lässt sich aber durch das Verfahren auch problemlos umsetzn.

4. Skalierbarkeit: Fragt euch einfach mal, warum das suchen einer Datei, ohne das auch nur irgendwas vom Inhalt untersucht wird, auf durchschnittlichen Laufwerken mehrere Minuten dauert? Filesysteme sind keine Datenbank, sondern bekommen durch irgendwelche Index Funktionen dann nach und nach mehr oder weniger akzeptable Geschwindigkeiten bei solchen Suchvorgängen. Die Architektur von Filesystemen und Datenbanken unterscheiden sich aber erheblich. Die Datenbankvariante kann die Archiv Datenbank auch auf verscheidene Laufwerke oder unterschiedliche Server verteilen. Beim Schrieben der Dateien knnt ihr via trigger in der gleichen Transaktion der PDF Inhalt in mehrere DB Server eintragen. Das geht alles mit Firebird in wenigen Zeilen Quelltext ab Version 2.5

5. Transaktionssicherheit: Du kannst den Inhalt deiner DB löschen und machst danach einen Rollback und schon ist wieder alles da. Das geht im Filesystem nur sehr begrenzt, in Netzwerkumgebungen auf Netzwerkshares dann schon gar nicht.

6. Isolierung gegen Fremdzugriffe: Wer eine PDF Datei in der DB ändern oder löschen will, muss die DB Schnittstelle benutzen. Irgendwelche amoklaufenden Antivirenscanner oder Backuptools können höchstens die Gesamte DB zerlegen, nicht aber Teil davon, in denen so ein blödes Antivirenprogramm mal wieder meinte, was verdächtiges zu finden und das dann einfach mal ungefragt in die Quarantäne zu verschieben, um es von dort nach 30 Tagen ganz zu löschen, ohne das es jemand gemerkt hat

7. Weitere Vorteile, die wir noch dazu nutzen, sind zum Beispiel Replikation von Blobinhalten und diverse andere mehr. Neben PDFs sind auch Excel dateien, dxf zeichnungen uvm in der DB, für die nach einer Änderung automatisch auch alte Versionen gespeichert werden, so das man ein nahezu unbegrenztes Undo zur Verfügung hat.

Ich könnte noch diverse weitere Punkte aufführen, aber dafür ist es mir jetzt zu spät .... ;-)

[Luckie]

Die Anzahl der Dateien in einem Verzeichnis muss begrenzt sein, da es den Ganzzahldatentyp "Unendlich" noch nicht gibt. ;)

Und wer noch den Explorer unter Windows benutzt? 99% aller Anwender würde ich sagen. Ich kenne nur eine Person, die den Total Commander benutzt, aber nur weil diese Person beruflich eine Lizenz besitzt (und sie auch privat nutzt). Davon abgesehen hängt die maximale Anzahl von Dateien nicht vom verwendeten Dateiexplorer ab, sondern vom zugrundeliegenden Dateisystem.

https://social.msdn.microsoft.com/Fo...n-einem-ordner

[RWarnecke]

Ich habe mal vor einiger Zeit mit der Version, dass die PDF's in der Datenbank gespeichert werden herumexperimentiert. Damals habe ich nur eine Firebird 2.1 Datenbank benutzt. Ich habe noch so in Erinnerung, dass das Speichern und dann das Öffnen keine Problem dargestellt hat. Nur wurde aus irgendeinem Grund ein Datensatz gelöscht, hat die Firebird Datenbank Ihre ursprüngliche Dateigröße beibehalten und wurde somit natürlich größer wenn noch weitere Dateien in der Datenbank geschrieben wurden. Ist das mittlerweile nicht mehr so oder gibt es hier für Firebird jetzt einen Befehl, womit ich die Dateigröße der Datenbank wieder reduzieren kann, nachdem ein Dokument gelöscht wurde ?

Wie sieht das ganze bei anderen DBMS aus ? Habe ich hier das gleiche Problem wie bei Firebird ?

Aus den oben genannten Experimenten und dessen Erfahrungen geht meine Tendenz dazu, dass die Dateien in einem Verzeichnis gespeichert werden und in der Datenbank nur der Dateilink steht. Wobei die letzten Posts mir gezeigt haben, dass ich sicherlich mehr Vorteile habe, die Dateien in einer Datenbank zu speichern. Ich bin aber immer noch von keiner der beiden Varianten so richtig überzeugt.

[mkinzler]

Zitat:

Wie sieht das ganze bei anderen DBMS aus ? Habe ich hier das gleiche Problem wie bei Firebird ?

Genauso, den Vergrößern/Verkleienern der Datenbankdatei bedeutet Aufwand. Die Datei kann man aber durch Backup/Restore/ShrinkDB verkleinern.

Das würde ich aber nicht als Problem ansehen, da der datenbankbestand ja tendeziell größer wird und der nächste Insert im frei gewordenen Platz erfolgt.

[hanspeter]

Zumindest bei Firebird wird eine Datenbank mit dem Schreiben nur größer.
Mit dem Löschen frei gewordener Speicher wird nicht an das OS zurück gegeben aber beim Einfügen neuer Datensätze verwendet.

Zum eigentlichen Problem.
Ich würde die Dokumente in der Datenbank speichern.
1. Diese sind besser geschützt, da Zugriffsrechte vergeben werden können.
2. Backup, Archivierung u.s.w. sind einfacher handelbar und im laufenden Betrieb möglich.
3. Wenn notwendig könnte eine Zugriffsverwaltung die Nutzung loggen.
4. Im Netzwerk einfacher handelbar als ein freigegebenes Filesystem.
5. Zugriff von unterschiedlichen Plattformen/Betriebssystemen einfacher möglich.
6. In einigen Bereichen (z.B. Röntgenaufnahmen) ist die Abspeicherung in einer Datenbank aus Sicherheitsgründen gesetzlich vorgeschrieben.
Nur so kann eine Datei gegen Manipulation oder Verlust geschützt werden.

Gruß Peter

[taveuni]

Die Beantwortung dieser Frage hängt auch von der Architektur der Applikation ab.
Handelt es sich nämlich um eine Multitier Anwendung in welcher der Client keinen direkten Zugriff auf die Datenbank hat macht es sehr wohl Sinn die Dateien separat zu speichern. Denn als Blob abgelegt müssten diese dann pro Anfrage ebenfalls durchgereicht werden. Wir lösen dies immer so dass wir die Dateien auf einem Webserver (kann auch innerhalb des Serverdienstes laufen) ablegen. Dann wird dem Client immer nur der Link mitgeteilt. Der Zugriff kann dann auch (http-) Passwortgeschützt erfolgen - so dass nur die Applikation das Dokument abrufen kann. Die Übertragung der Datei kann sogar verschlüsselt erfolgen (SSL).

[mkinzler]

Das zusätzlich Ablegen ist aber nicht nötig, den man kann das Dokumnet auch direkt aus der Datenbank an den Client Streamen.

[taveuni]

Zitat:

Zitat von mkinzler (Beitrag 1287229)

Das zusätzlich Ablegen ist aber nicht nötig, den man kann das Dokumnet auch direkt aus der Datenbank an den Client Streamen.

Hmhh..
Deshalb habe ich geschrieben: "Wo der Client keinen direkten Zugriff auf die Datenbank hat". Im Umfeld wo wir Software machen sind Datenbankzugriffe ab Client verboten

[sh17]

Mal als Zwischengedanke:

Macht es Sinn die Dateien in der Datenbank zu komprimieren? Gerade bei PDF ist da sicher etwas herauszuholen.

[Bernhard Geyer]

Wir haben die Dateien außerhalb der DB liegen und haben damit wenige Probleme.
Haben aber auch viele HTML/XML-Dokumente die gemeinsame CSS und JS-Dateien verwenden. Hier müssten wir uns ein Logik überlegen wie wir diese mit ablegen ohne das Problem zu haben bei zentraler änderung diese überall ändern zu müssen. Auch haben wir die Anforderung bei manchen Kunden das diese Dokumente von einem anderen System geändert werden müssen (aktualisieren) ohne das diese dann neu bei uns Importiert werden müssen.

[Sherlock]

Solltest Du dennoch bei der Dateisystem Variante bleiben wollen: http://stackoverflow.com/questions/1...nd-directories

Gescheite Datenbanken sollten dieses Problem nicht haben.

Sherlock

[Bernhard Geyer]

Zu den vielen Dateien in einem Verzeichnis:
Es gibt ja noch gruppierungsmöglichkeiten. Z.B. Anlegen nach Jahr/Monat (2015-01 für alle Dokumente die in diesem Monat dazu kommen) oder ähnliches. Was hier sinnvoll ist wird entsprechend dem Anwendungsfall sein.

[Perlsau]

Zitat:

Zitat von sh17 (Beitrag 1287231)

Macht es Sinn die Dateien in der Datenbank zu komprimieren? Gerade bei PDF ist da sicher etwas herauszuholen.

Nicht wirklich: PDF-Dateien sind meiner Kenntnis und Erfahrung nach bereits komprimiert und lassen sich z.B. durch 7zip – dem meiner Meinung nach effizientesten Packer – nur noch unwesentlich weiter "zusammenpressen".

Zudem hast du bei komprimierten PDF-Dateien das Problem, daß du die Datei vor dem Anschauen erst entpacken mußt, statt sie einfach dorthin streamen zu können, wo sie angezeigt werden soll. Um den Komprimierungsgrad größerer PDF-Sammlungen zu testen, würde ich einfach mal ein paar Verzeichnisse, die PDF-Dateien enthalten, mit 7zip komprimieren, um so die Größe der komprimierten Ordner mit der der ursprünglichen Ordner vergleichen zu können.

Falls es möglich wäre, komprimierte Datenbank-Inhalte im Speicher zu entpacken und dann zu streamen, könnte man das letztgenannte Problem natürlich umgehen. Ich hatte das mal in einer Anwendung versucht, die HTML-Vorlagen in einer Datenbank verwaltet und mit TWebbrowser anzeigt. Es ist mir nicht gelungen, dem TWebbroser irgendwas zuzustreamen. In dieser Anwendung mußte ich HTML-Vorlagen aus der DB immer erst in einen bestimmten Ordner speichern, um sie mit TWebbrowser anzeigen zu können (navigate). Bei der geringen Größe der jeweiligen Blob-Felder spielte es daher auch keine große Rolle, ob die Daten in der DB gezippt vorlagen.

[Bernhard Geyer]

Zitat:

Zitat von Perlsau (Beitrag 1287247)

Zitat:

Zitat von sh17 (Beitrag 1287231)

Macht es Sinn die Dateien in der Datenbank zu komprimieren? Gerade bei PDF ist da sicher etwas herauszuholen.

Nicht wirklich: PDF-Dateien sind meiner Kenntnis und Erfahrung nach bereits komprimiert und lassen sich z.B. durch 7zip – dem meiner Meinung nach effizientesten Packer – nur noch unwesentlich weiter "zusammenpressen".

PDFs lassen sich noch stark komprimieren - Aber nicht mit "dummen" Programmen wie 7zip und Co sondern nur indem z.B. die PDF-Version hochgesetzt wird oder auf altcompatiblität mit Reader 7.x und Co. keine Rücksicht nimmt. Oder eingebeddete Zeichnungen statt im JPEG im JPEG2000-Format (und mit geringerer DPI-Auflösung) speichern lässt.

Zitat:

Zitat von Perlsau (Beitrag 1287247)

Falls es möglich wäre, komprimierte Datenbank-Inhalte im Speicher zu entpacken und dann zu streamen, könnte man das letztgenannte Problem natürlich umgehen. Ich hatte das mal in einer Anwendung versucht, die HTML-Vorlagen in einer Datenbank verwaltet und mit TWebbrowser anzeigt. Es ist mir nicht gelungen, dem TWebbroser irgendwas zuzustreamen.

Sollte kein Problem darstellen. Jedoch solltest du nicht direkt streamen sondern per http. D.h. dein Programm spielt Webserver für die TWebBrowser-Instanz. ICS z.B. bietet hierfür einen einfach einzusetzende Serverkomponente.

[Perlsau]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1287251)

PDFs lassen sich noch stark komprimieren - Aber nicht mit "dummen" Programmen wie 7zip und Co sondern nur indem z.B. die PDF-Version hochgesetzt wird oder auf altcompatiblität mit Reader 7.x und Co. keine Rücksicht nimmt. Oder eingebeddete Zeichnungen statt im JPEG im JPEG2000-Format (und mit geringerer DPI-Auflösung) speichern lässt.

Das ist wohl richtig :thumb: Ich bin jedoch davon ausgegangen, daß die Originalversionen der PDF-Dateien unverändert archiviert werden sollen. Wenn ich meine komplette PDF-Sammlung (mehrere TB) auf diese Weise komprimieren wollte, säße ich nächstes Jahr noch daran :)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1287251)

Zitat:

Zitat von Perlsau (Beitrag 1287247)

Falls es möglich wäre, komprimierte Datenbank-Inhalte im Speicher zu entpacken und dann zu streamen, könnte man das letztgenannte Problem natürlich umgehen. Ich hatte das mal in einer Anwendung versucht, die HTML-Vorlagen in einer Datenbank verwaltet und mit TWebbrowser anzeigt. Es ist mir nicht gelungen, dem TWebbroser irgendwas zuzustreamen.

Sollte kein Problem darstellen. Jedoch solltest du nicht direkt streamen sondern per http. D.h. dein Programm spielt Webserver für die TWebBrowser-Instanz. ICS z.B. bietet hierfür einen einfach einzusetzende Serverkomponente.

Danke :thumb: Hab ich mir notiert und werd es mir bei Gelegenheit mal reinziehn.

[mm1256]

Zitat:

Zitat von RWarnecke (Beitrag 1287221)

Aus den oben genannten Experimenten und dessen Erfahrungen geht meine Tendenz dazu, dass die Dateien in einem Verzeichnis gespeichert werden und in der Datenbank nur der Dateilink steht. Wobei die letzten Posts mir gezeigt haben, dass ich sicherlich mehr Vorteile habe, die Dateien in einer Datenbank zu speichern. Ich bin aber immer noch von keiner der beiden Varianten so richtig überzeugt.

Letzendlich ist es doch so, dass jede Variante ihre Vor- und Nachteile hat. Man kann das noch zu tode diskutieren, doch, das komfortable an dieser Situation ist, dass keine Variante eine Einbahnstraße darstellt. Wenn du jetzt mit Dateien beginnst, und irgendwann mal feststellst, dass eine DB-Lösung doch intelligenter oder praktischer wäre, dann ist doch ein kleines Tool das die Dateien in die DB aufnimmt und die Änderung der Anzeigelogik mit wirklich sehr wenig Zeitaufwand schnell geschrieben. Und umgekehrt genauso. Wenn es die DB aus welchen Gründen auch immer nicht oder nicht mehr bringt, dann switcht man einfach um auf externe Dateien.

Schön, wenn das Programmiererdasein immer so einfach wäre :thumb:

[p80286]

Ich habe die Erfahrung gemacht, daß die Datenbank (genügend Speicherplatz vorrausgesetzt) sich gut für Dokumente eignet, die nicht mehr "gebraucht" werden. Dokumente die noch bearbeitet werden (können/sollen/müssen) sind auf Fileservern besser aufgehoben. Wobei hier natürlich auch ein wenig organisiert werden muß,z.B. Verzeichnisnamen, die sich an Aktennummern orientieren. Die mehr oder weniger freie Zugänglichkeit ist gleichzeitig das große Risiko, eine Fehlbedienung und die Dateien sind futsch.

Gruß
K-H

[Sharky]

Zitat:

Zitat von RWarnecke (Beitrag 1287201)

Zitat:

Zitat von Dejan Vu (Beitrag 1287189)

SQL-Server (ab Version 2012) bietet die FileTables, was eine Kombination von beidem ist.

Das hört sich zumindest mal interessant an. Da werde ich mal ein wenig nach recherchieren.

Kleiner Tipp von mir.
Kaufe Dir die MS-SQL2012 developer Edition (liegt so bei 60 Euro).
Das ist die vollwertige Enterprise Edition mit der Einschränkung das Du sie nicht produktiv nutzen darfst.

[vagtler]

Zitat:

Zitat von Sharky (Beitrag 1287268)

[...] Kaufe Dir die MS-SQL2012 developer Edition (liegt so bei 60 Euro). [...]

Und warum nicht die aktuelle Version SQL Server 2014?

[RWarnecke]

Zitat:

Zitat von mm1256 (Beitrag 1287256)

Letzendlich ist es doch so, dass jede Variante ihre Vor- und Nachteile hat. Man kann das noch zu tode diskutieren, doch, das komfortable an dieser Situation ist, dass keine Variante eine Einbahnstraße darstellt. Wenn du jetzt mit Dateien beginnst, und irgendwann mal feststellst, dass eine DB-Lösung doch intelligenter oder praktischer wäre, dann ist doch ein kleines Tool das die Dateien in die DB aufnimmt und die Änderung der Anzeigelogik mit wirklich sehr wenig Zeitaufwand schnell geschrieben. Und umgekehrt genauso. Wenn es die DB aus welchen Gründen auch immer nicht oder nicht mehr bringt, dann switcht man einfach um auf externe Dateien.

Mmh, darüber habe ich noch nicht so genau nachgedacht, das ja ein Switch zwischen Datenbank und Verzeichnis für die Ablage von PDF-Dokumenten recht einfach sein kann, wenn man bei der Programmierung gleich entsprechend aufpasst. Und dann noch die Dateien entweder ins Verzeichnis oder in die Datenbank migrieren, wäre ja auch mit einem kleinen Tool schnell erledigt. Der Gedanke hat irgendwie Scharm, da muss ich mal weiter drüber nachdenken.

Zitat:

Zitat von Sharky (Beitrag 1287268)

Zitat:

Zitat von RWarnecke (Beitrag 1287201)

Zitat:

Zitat von Dejan Vu (Beitrag 1287189)

SQL-Server (ab Version 2012) bietet die FileTables, was eine Kombination von beidem ist.

Das hört sich zumindest mal interessant an. Da werde ich mal ein wenig nach recherchieren.

Kleiner Tipp von mir.
Kaufe Dir die MS-SQL2012 developer Edition (liegt so bei 60 Euro).
Das ist die vollwertige Enterprise Edition mit der Einschränkung das Du sie nicht produktiv nutzen darfst.

Danke für den Tipp, aber ich bin im Microsoft Developer/Partner-Programm. Da habe ich Zugriff auf alle SQLServer Varianten, dass stellt ein Problem dar.


Das sind alles schonmal gute bis sehr gute Hinweise. Darüber werde ich jetzt mal nachdenken und ein paar Tests durchführen mit den unterschiedlichen Datenbanksystemen und bei eventuellen Fragen nochmal melden.

[DeddyH]

Zitat:

Zitat von RWarnecke (Beitrag 1287271)

Da habe ich Zugriff auf alle SQLServer Varianten, dass stellt ein Problem dar.

So krass würde ich das aber nicht ausdrücken :lol: (SCNR)