AW: Anwendungsdesign: WO Dateianhänge speichern?
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...
|
AW: Anwendungsdesign: WO Dateianhänge speichern?
Ich denke, dass es dabei keine allgemein gültige Lösung geben kann. Es kommt auf den Einsatzzweck an.
Wenn die Dateien nur zu Archivierungszwecken gespeichert werden, finde ich die BLOB-Lösung am schönsten. Setzt aber voraus, dass die Dateien möglichst nicht bearbeitet werden müssen. Wenn man aber z.B. Textdokumente hat (Briefe, usw.), die von Zeit zu Zeit mit externen Programmen bearbeitet werden, müsstest Du sie aus dem Blob raus holen, bearbeiten in der Textverarbeitung wieder ins Blob einlesen. Ist fehleranfällig. Anders herum, wenn Du z.B. bei irgendwelchen Buchungen zu Dokumentationszwecken vielleicht ein Bild einer Webcam speichern willst, würde ich das in der Datenbank speichern. Die Größe der Datenbank dürfte bei heutigen Systemen nicht mehr der limitierende Faktor sein. |
AW: Anwendungsdesign: WO Dateianhänge speichern?
Zitat:
Und je nach Eingang (freie Dokumente) kann das auch mal recht groß werden. (Der Versicherungsnehmer scannt eben ein paar Dokumente mit 1200 dpi und hängt noch ein paar Fotos vom Schaden an und dann hat man ein 100 MB Email) |
AW: Anwendungsdesign: WO Dateianhänge speichern?
Wenn man ein Datenbanksystem benutzt, oder auch das lokale unsichtbare Dateisystem zur Ablage der Dateien verwendet, könnten man gegen die Anwendung ein virtuelles Dateisystem integrieren, sodass sich für den Anwender alles "normal" anfühlt. Auf diese Weise können Dokumente ganz einfach bearbeitet werden. Man könnte automatisch eine Versionierung und auch ein Rechtesystem anbieten. Und die Dateien sind so auch gut gegen Verschlüsselungstrojaner geschützt. Auch ein wichtiger Punkt.
Die Firma Eldos bietet ein solches Produkt. Ansonsten Dokany, da hab ich den Wrapper mal eine Weile aktuell gehalten. Müsste mal wieder einer ran https://github.com/dokan-dev/dokan-delphi Oder https://github.com/billziss-gh/winfsp - eine Abspaltung/Neuentwicklung von Dokany, weil er mit der Architektur von Dokany nicht zufrieden war. Aus Datensicherungsgründen packen wir im Moment alle Dokumente zu einem Vorgang (Das Anwendungsdesign macht es möglich) mit Versionierung in eine SQLite-DB. So sind bei einem Ausfall nicht alle Daten betroffen. Abgerufen werden die Dateien über ein REST-API |
AW: Anwendungsdesign: WO Dateianhänge speichern?
Danke euch schon mal für die vielen Meinungen!
Zitat:
|
AW: Anwendungsdesign: WO Dateianhänge speichern?
Google mal nach Rechnungen schreiben mir Word oder Excel. Dann dürfte schnell klar werden, was da letztendlich gemeint ist: Das Windows-Dateisystem ist vollig ungeeignet zum Archivieren, weil Änderungen nicht zuverlässig ausgeschlossen werden können, und wenn doch Änderungen erfolgen, werden sie nicht protokolliert. Die bereits angesprochene Datenbanklösung in Verbindung mit Protokollierung von Änderungen ist daher das Mittel der Wahl. Natürlich mit den entsprechenden Erweiterungen für Zugriffsrechte, Protokollierung usw.
|
AW: Anwendungsdesign: WO Dateianhänge speichern?
Das klingt doch sehr nach einer WORM, gibt's die überhaupt noch?
Auf klassischen (Magnet-)Datenträger könnte man sich mit create/read-Rechten behelfen, aber da gibt es einige Hintertüren um die Dateien doch noch zu manipulieren..... Gruß K-H |
AW: Anwendungsdesign: WO Dateianhänge speichern?
Bevor wir hier ins Philosophische abdriften: Kennt sich hier jemand mit den GoBD aus? Ich würde gern wissen ob dort tatsächlich die Unveränderlichkeit von Dateien gefordert wird oder ob es reicht, stattgefundene Änderungen zu entdecken. Sprich ob die Hashwert-Lösung ausreichend ist. Eine echte Unveränderlichkeit lässt sich nur über Readonly-Datenträger erreichen und hätte natürlich ganz erhebliche Auswirkungen auf den Handlingprozess innerhalb der Unternehmen.
EDIT: Eigentlich ergibt sich aus den GoBD noch eine ganz andere Frage: Sind Open-Source-Lösungen jedweder Art nicht per GoBD-Definition ausgeschlossen? Wenn ich die Lösungen etablierter Anbieter wie Lexware, Datev, Dokumentenmanagementsysteme usw. anschaue, dann basieren die alle auf dem Prinzip der "Security by Obscurity": Eine elektronisch gespeicherte Datei in einem Fremdformat (z.B. PDF, JPEG usw.) wird durch geheime Schlüssel, Hashes o.ä. gesichert. Würden diese bekannt, ließen sich dem System auch wieder veränderte Daten unterschieben, deren Prüfwerte man nachträglich neu berechnet und mit einfügt. Klingt für mich so als könnte Open-Source-Software solche Vorgaben prinzipbedingt nicht erfüllen, da alle mathematischen Verfahren offen liegen. |
AW: Anwendungsdesign: WO Dateianhänge speichern?
Zitat:
http://www.bundesfinanzministerium.d...cationFile&v=3 Zitat:
http://www.psp.eu/media/allgemein/Go..._2_4_FINAL.pdf Zitat:
Das fett markierte im zweiten Zitat sagt eigentlich alles. Wenn du einen Datensatz hast und den änderst, muss später nachträglich erkennbar bleiben was da mal stand. Änderungsprotokoll sei hier als Stichwort genannt (was stand zum Zeitpunkt A da, was steht jetzt danach zum Zeitpunkt B). Eine Hash-Kette wäre zum Beispiel eine Lösung, um miteinander zusammenhängende Datensätze gegen Manipulation zu schützen. Das Verfahren muss natürlich den Stand der Technik entsprechen. Was natürlich gar nicht geht sind so Sachen wie bspw. das du Rechnungsaufzeichnungen aus der Vergangenheit hast und nur weil du Preise oder Steuersätze jetzt aktuell im Programm änderst, diese alten Daten überschrieben/angepasst werden. Auf Wunsch kann ich dir per PN den Namen eines guten Beratungsunternehmen für das Thema nennen. |
AW: Anwendungsdesign: WO Dateianhänge speichern?
Auch wenn TiGü die wesentlichen Aspekte schon genannt hat, noch ein Hinweis: Grundlage aller Überlegungen ist die Buchführung in Journalen. In diesen werden Erfassungsfehler durchgestrichen und die korrekten Daten in einem neuen Datensatz erfasst. Fehlbuchungen werden über Korrekturbuchungen berichtigt. Und solange der Prüfer die vorhandene Buchführung akzeptiert ist alles in Ordnung. Die Dokumente die der Buchung zu Grunde liegen sollten nicht editierbar sein, Bleistift wird hier nicht akzeptiert!
Für Dich heißt das, du solltest tunlichst keine Word-Dateien sondern z.B. PDF-A - Dateien verwenden. Hier findest Du einen Einstieg: https://de.wikipedia.org/wiki/Revisionssicherheit https://de.wikipedia.org/wiki/Elektr...e_Archivierung Gruß K-H |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz