Anwendungsdesign: WO Dateianhänge speichern?

[Codehunter]

Moin!

Man kennt das ja von diversen Wawi- und Fibu-Systemen: Zu einzelnen Datensätzen können eine oder mehrere Dateianhänge wie z.B. eingescannte Fremdbelege angefügt werden. Ich habe nun schon viele verschiedene Softwares gesehen. Da gab es schlechte Lösungen und noch schlechtere. Das übelste das mir jemals unter gekommen ist war ein Wawi, welches bei Dateianhängen lediglich einen Datei-Öffnen-Dialog zeigte und dann den dort gewählten Dateipfad als String in ein varchar()-Feld schrieb. Das war irre praktisch wenn man eine Mehrplatzinstallation hatte, ein Anwender mal fix ein PDF von seinem USB-Stick angehängt hat und der andere panisch den Wawi-Support anrief weil er an die Anhänge nicht ran kam

Eine Variante davon ist, wenn eine Client-Server-Installation konstruktivisch ein Netshare voraus setzt, wo solche gemeinsam genutzten Dateien abgelegt werden. Das funktioniert so lange reibungslos, wie man seine Software über Distributoren mit Wartungsverträgen vertreibt. Da kann man davon ausgehen, dass Netshares auch überall, z.B. per GPO mit dem selben Laufwerksbuchstaben laufen oder aber ein korrekter UNC verwendet wird. Bei Consumer-Software wie z.B. Vereinsverwaltungen dagegen funktioniert das wieder eher schlecht als recht, weil sich die typische Clientel selten mit Domaincontrollern, Zugriffsrechten und/oder DNS-Problemen befasst.

Die dritte Lösung die ich kenne ist, Dateien als BLOB direkt in die Datenbanken zu speichern. Damit geht man zwar was die Verfügbarkeit angeht auf Nummer sicher, bläht seine DB aber ungemein auf und ist in der Regel auch gezwungen eine Dateigrößenbeschränkung zu führen. Das gibt auch wieder Frust bei den Anwendern, wenn der Import eines 100 MB großen, mit 4096 dpi (interpoliert!) gescannten Dreiseiters mit einer Fehlermeldung abwürgt und keiner weiß, wie man ein PDF kleiner bekommt.

Wie löst ihr diese Aufgabenstellung? Gibt es noch andere Lösungswege die ich noch nicht kenne? Ich bin da neugierig

Viele Grüße
Cody

[jaenicke]

Mir fällt da z.B. MongoDB GridFS ein. Das ist quasi wie ein Dateisystem auf eine NoSQL Datenbank gestülpt.

[TigerLilly]

Wen du einen performanten DB-Server im Hintergrund hast mit viel Speicher + Plattenplatz und ein DB-System, das die Verwaltung von eingebetteten Dokumenten gut unterstützt (zB FILESTREAM by MSSQL), dann ist es besser, wenn die Docs in der DB landen.

Eine Alternative ist es, in der DB nur den relativen(!) Pfad zu den Dokumenten zu speichern + je User einen Root-Pfad zum Dokumenten-Verzeichnis zu führen.

[mjustin]

In der eigenen Software ein DB-Feld mit einer GUID oder einem anderen Identifier, eventuell auch der Dateianhangname.
Die Dokumente gehören in ein System zur Dokumentenverwaltung wie Alfresco.
Das Rad muss nicht viereckig neu erfunden werden Ü

[Aviator]

Alfresco speichert die Daten allerdings auch nur in einem Verzeichnis auf einem Rechner/Server ab. Die bekommen dann eine ID, lassen sich aber mit dem, für den Dateityp, passenden Programm direkt öffnen wenn man auf das Verzeichnis Zugriff hat. Da wird also auch nichts verschlüsselt.

[mjustin]

Zitat von Aviator:

Alfresco speichert die Daten allerdings auch nur in einem Verzeichnis auf einem Rechner/Server ab. Die bekommen dann eine ID, lassen sich aber mit dem, für den Dateityp, passenden Programm direkt öffnen wenn man auf das Verzeichnis Zugriff hat. Da wird also auch nichts verschlüsselt.

Ist das Repository nicht eher eine Datenbank mit diversen Views (CIFS, SMB, FTP, WebDAV) und APIs als eine nackte Verzeichnisstruktur?

Zitat:

The actual binary streams of the content are stored in files managed in the repository, although these files are for internal use only and do not reflect what you might see through the shared drive interfaces.

http://docs.alfresco.com/4.0/concept...epo-about.html

[p80286]

Zitat von Codehunter:

Eine Variante davon ist, wenn eine Client-Server-Installation konstruktivisch ein Netshare voraus setzt, wo solche gemeinsam genutzten Dateien abgelegt werden. Das funktioniert so lange reibungslos, wie man seine Software über Distributoren mit Wartungsverträgen vertreibt. Da kann man davon ausgehen, dass Netshares auch überall, z.B. per GPO mit dem selben Laufwerksbuchstaben laufen oder aber ein korrekter UNC verwendet wird. Bei Consumer-Software wie z.B. Vereinsverwaltungen dagegen funktioniert das wieder eher schlecht als recht, weil sich die typische Clientel selten mit Domaincontrollern, Zugriffsrechten und/oder DNS-Problemen befasst.

One fits all, kannst Du vergessen. Irgendeiner der handelden (incl. des Programmierers) bringt es fertig einen Scan eines Dokumentes als Dokument und nicht als Bild abzulegen, und dann knirscht es wieder mal im Gebälk. Und dabei ist es egal ob Du die Daten als Datei in einem FS ablegst oder als BLOB in einer/der Datenbank ablegst. Nach meiner Erfahrung hast Du bei extern abgelegten Daten wenigstens eine Chance im Falle eines Falles die Daten zu reanimieren, sofern der Dateiname einen eindeutigen Hinweis auf den Datenbankeintrag beinhaltet. Falls die DB struwellig wird ist der Aufwand um einiges höher (nach meiner Erfahrung).

Gruß
k-H

[jobo]

Ein DMS wie Alfresco scheint mir eine vernünftige Lösung, auch wenn ich es im Detail nicht kenne. Passt vielleicht nicht unbedingt ins Konzept einer jeden Software.
Wir machen es so, dass die Datenbank Dateiname, Pfad, Typ und die Datei selbst in einem BLOB schluckt.
Darüber liegt für Webclients eine Schicht, die webbasierten Upload und Download unterstützt und es per Default (ursprünglich) in die DB schiebt, analog zum FAT Client.
Da die Dokumente alle ein fachlichen Zusammenhang haben und damit einen mehr oder weniger festen Dokumenttyp, kann für den fachlichen Vorgang definiert werden, ob der Webclient das Dokument vor dem Upload komprimiert/(mehrere) gezippte Dateien erwartet und ob es in die DB oder im FS des Webserver oder doppelt abgelegt werden soll. Jede Datei die hochgeladen wird, wird umbenannt und mit der ID des Datensatzes versehen, unter dem der Vorgang und die Metadaten dazu abgelegt sind.
Damit realisieren wir hauptsächlich den Transfer von Importdaten (z.B. CSV, gezipt) oder den Export von CSV, Reports, Spreadsheet Reports.
Der Transfer zum DBServer bietet für den Import den Vorteil, dass dort lokal dann mit proprietäten Verfahren sehr schnell große Datenmengen importiert werden können. Das Verfahren bietet eine Menge Möglichkeiten für Review, Reimport usw., die Erfahrung hat leider gezeigt, dass CSV Daten beliebig schlecht sein können und maximale Flexibilität auch maximale Entspannung bei Datenproblemen bietet.
Für reine Dokumenten Verwaltung / Nachweis / OCR review ist das natürlich in der Form nicht notwendig.

[Rollo62]

Ich würde es so machen das nur der relative Pfad in der DB gespeichert wird.
So dann man von aussen entscheided wo genau das jetzt liegt, Serververzeichnis, FTP, WebDav, Cloud, etc.
Dann würde die DB auch bei grundsätzlichem Wechsel der Systeme noch stabil laufen, ohne upgedatet werden zu müssen.

Rollo

Update
Ok, TigerLilly hatte ja schon ähnliches Vorgeschlagen.

[Mikkey]

Wenn mit einer großen Zahl von Anlagen unterschiedlicher Größe umgegangen werden soll und ein BLOB-Eintrag in der Datenbank selbst nicht infrage kommt, würde ich...

• In einer Anlagen-Tabelle die Metadaten (und u.U ein Thumbnail) speichern, dazu eine Repository-Id und einen zum Repository relativen Pfad.
• Eine Repository-Tabelle identifiziert die Speicherorte (die auf diese Weise einfach umziehen können).
• Jedes Repository kann durch einen gesonderten Prozess verwaltet werden, so dass händische Eingriffe in die Repositorys unterbunden werden können. Die Datei erhält als Namen lediglich die ID des Anlagen-Eintrags.

Die Abfrage kann so auch passend darauf reagieren, wenn ein Repository gerade nicht zur Verfügung steht.