Anwendungsdesign: WO Dateianhänge speichern?

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