PDF-Dokumente in eine Datenbank oder nicht

[RWarnecke]

Zitat von mkinzler:

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

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

Zitat von sh17:

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.

[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

[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.