PDF-Dokumente in eine Datenbank oder nicht

**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

**mm1256**

Zitat von RWarnecke:

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

**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

**RWarnecke**

Zitat von mm1256:

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 von Sharky:

Zitat von RWarnecke:

Zitat von Dejan Vu:

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.