PDF-Dokumente in eine Datenbank oder nicht

[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 von mkinzler:

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

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