PDF-Dokumente in eine Datenbank oder nicht

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