AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Anwendungsdesign: WO Dateianhänge speichern?

Anwendungsdesign: WO Dateianhänge speichern?

Ein Thema von Codehunter · begonnen am 11. Aug 2017 · letzter Beitrag vom 28. Aug 2017
Antwort Antwort
Seite 2 von 3     12 3   
Mikkey

Registriert seit: 5. Aug 2013
265 Beiträge
 
#11

AW: Anwendungsdesign: WO Dateianhänge speichern?

  Alt 13. Aug 2017, 13:02
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.
  Mit Zitat antworten Zitat
Benutzerbild von Nersgatt
Nersgatt

Registriert seit: 12. Sep 2008
Ort: Emlichheim
680 Beiträge
 
Delphi 10.1 Berlin Professional
 
#12

AW: Anwendungsdesign: WO Dateianhänge speichern?

  Alt 14. Aug 2017, 11:13
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.
Jens
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.482 Beiträge
 
Delphi 2010 Enterprise
 
#13

AW: Anwendungsdesign: WO Dateianhänge speichern?

  Alt 14. Aug 2017, 13:02
Die Größe der Datenbank dürfte bei heutigen Systemen nicht mehr der limitierende Faktor sein.
so an sich nicht unbedingt, aber dann gibt es da hinten dran noch Backupsysteme und wenn es nicht filigran gemacht ist, bedeutet ein Änderung des Datensatz evtl erneutes Backup (Log).
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)
Gruß, Jo
  Mit Zitat antworten Zitat
Benutzerbild von sh17
sh17

Registriert seit: 26. Okt 2005
Ort: Radebeul
1.464 Beiträge
 
Delphi 10.3 Rio
 
#14

AW: Anwendungsdesign: WO Dateianhänge speichern?

  Alt 15. Aug 2017, 06:58
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
Sven
--

Geändert von sh17 (15. Aug 2017 um 07:01 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
1.813 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#15

AW: Anwendungsdesign: WO Dateianhänge speichern?

  Alt 15. Aug 2017, 08:36
Danke euch schon mal für die vielen Meinungen!

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.
Hier kommt noch ein Faktor hinzu, den ich im Eingangspost noch nicht erwähnt hatte, nämlich dieses wunderbar Produktivzeit vernichtende GoBD. Damit habe ich mich aber auch erst NACHDEM ich das Erstpost geschrieben hatte befasst. Insofern dürfen in manchen Fällen angehängte Dateien gar nicht mehr verändert werden können. Zumindest nicht ohne dass es dem System auffällt. GoBD schreibt außerdem ausdrücklich vor, dass simple Netshares nicht ausreichend wären. Hieße für mich, wenn man schon mit Netshare arbeitet, in welcher Form auch immer, dann müsste man mindestens noch einen Hashwert der Datei speichern. Aber da ahne ich schon dass das supportlastig wird...
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber.
  Mit Zitat antworten Zitat
mm1256

Registriert seit: 10. Feb 2014
Ort: Wackersdorf, Bayern
640 Beiträge
 
Delphi 10.1 Berlin Professional
 
#16

AW: Anwendungsdesign: WO Dateianhänge speichern?

  Alt 24. Aug 2017, 15:45
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.
Gruss Otto
Wenn du mit Gott reden willst, dann bete.
Wenn du ihn treffen willst, schreib bei Tempo 220 eine SMS
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.298 Beiträge
 
Delphi 7 Personal
 
#17

AW: Anwendungsdesign: WO Dateianhänge speichern?

  Alt 24. Aug 2017, 22:24
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
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
1.813 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#18

AW: Anwendungsdesign: WO Dateianhänge speichern?

  Alt 25. Aug 2017, 07:22
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.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber.

Geändert von Codehunter (25. Aug 2017 um 08:24 Uhr)
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
2.109 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#19

AW: Anwendungsdesign: WO Dateianhänge speichern?

  Alt 25. Aug 2017, 08:17
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.
So hart wie es klingt, aber du wirst nicht drum herumkommen die GoBD und erklärende Dokumente zu lesen.

http://www.bundesfinanzministerium.d...cationFile&v=3

Zitat:
3.2.5 Unveränderbarkeit (§ 146 Absatz 4 AO, § 239 Absatz 3 HGB)
58 Eine Buchung oder eine Aufzeichnung darf nicht in einer Weise verändert werden,
dass der ursprüngliche Inhalt nicht mehr feststellbar ist. Auch solche Veränderungen
dürfen nicht vorgenommen werden, deren Beschaffenheit es ungewiss lässt, ob sie
ursprünglich oder erst später gemacht worden sind (§ 146 Absatz 4 AO, § 239
Absatz 3 HGB).
59 Veränderungen und Löschungen von und an elektronischen Buchungen oder Aufzeichnungen
(vgl. Rzn. 3 bis 5) müssen daher so protokolliert werden, dass die Voraussetzungen
des § 146 Absatz 4 AO bzw. § 239 Absatz 3 HGB erfüllt sind (siehe
auch unter 8). Für elektronische Dokumente und andere elektronische Unterlagen, die
gem. § 147 AO aufbewahrungspflichtig und nicht Buchungen oder Aufzeichnungen
sind, gilt dies sinngemäß.

http://www.psp.eu/media/allgemein/Go..._2_4_FINAL.pdf

Zitat:
7.2. Unveränderbarkeit48
Nach § 146 Absatz 4 AO darf eine Buchung oder Aufzeichnung nicht in einer Weise
verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist.49 Dazu
dürfen keine Veränderungen vorgenommen werden, die keinen Rückschluss darauf
zulassen, ob sie ursprünglich oder erst später initiiert wurden.50 Das zum Einsatz
kommende DV-Verfahren muss Gewähr dafür bieten, dass alle Informationen (Programme
und Datenbestände), die einmal in den Verarbeitungsprozess eingeführt
werden (Beleg, Grundaufzeichnung, Buchung), nicht mehr unterdrückt oder ohne
Kenntlichmachung überschrieben, gelöscht, geändert oder verfälscht werden können.
Bereits in den Verarbeitungsprozess eingeführte Informationen (Beleg, Grundaufzeichnung,
Buchung) dürfen nicht ohne Kenntlichmachung durch neue Daten
ersetzt werden.51

Die Unveränderbarkeit der Daten, Datensätze, elektronischer Dokumente und elektronischer
Unterlagen kann sowohl hardwaremäßig (z. B. unveränderbare und fälschungssichere
Datenträger) als auch softwaremäßig (z. B. Sicherungen, Sperren,
Festschreibungen, Löschmerker, automatische Protokollierung, Historisierungen,
Versionierungen) oder organisatorisch (z. B. mittels Zugriffsberechtigungskonzepten)
gewährleistet werden.52 Die Ablage von Daten und elektronischen Dokumenten
in einem Dateisystem erfüllt die Anforderungen der Unveränderbarkeit regelmäßig
nicht, soweit nicht zusätzliche Maßnahmen ergriffen werden, die eine Unveränderbarkeit
gewährleisten.53
Spätere Änderungen sind ausschließlich so vorzunehmen, dass sowohl der ursprüngliche
Inhalt als auch die Tatsache, dass Veränderungen vorgenommen wurden,
erkennbar bleiben.
Bei programmgenerierten bzw. programmgesteuerten Aufzeichnungen
sind Änderungen an den der Aufzeichnung zugrunde liegenden
Generierungs- und Steuerungsdaten ebenfalls aufzuzeichnen. Dies betrifft insbesondere
die Protokollierung von Änderungen in Einstellungen oder die Parametrisierung
der Software. Bei der Änderung von Stammdaten (z. B. Abkürzungen oder
Schlüssel) muss die eindeutige Bedeutung in den entsprechenden Bewegungsdaten
erhalten bleiben. Gegebenenfalls müssen Stammdatenänderungen ausgeschlossen
oder Stammdaten mit Gültigkeitsangaben historisiert werden, um eindeutige und
korrekte Verknüpfungen zu gewährleisten. Auch die Änderungshistorie darf nicht
nachträglich veränderbar sein.54 Werden Systemfunktionalitäten oder Manipulationsprogramme
eingesetzt, die diesen Anforderungen entgegenwirken, führt dies
zur Ordnungswidrigkeit der elektronischen Bücher und sonst erforderlicher elektronischer
Aufzeichnungen.55
Für einen Sachkundigen Dritten muss bei einer Prüfung immer ersichtlich sein, wer (!) was (!) wann (!) geändert hat.
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.
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.298 Beiträge
 
Delphi 7 Personal
 
#20

AW: Anwendungsdesign: WO Dateianhänge speichern?

  Alt 25. Aug 2017, 08:47
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
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:06 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf