AW: Darf man "File of <Record>" noch benutzen?
Zitat:
Wie gesagt man muss Vor- und Nachteile gegen einander abwägen. Ein Format mit festen Records hat da einfach zu viele Nachteile. |
AW: Darf man "File of <Record>" noch benutzen?
"File of <Record>" ?
Wenn es wirklich auf große Datenmengen und Geschwindigkeit ankommt, sind "Memory Mapped Files" die bessere Lösung. |
AW: Darf man "File of <Record>" noch benutzen?
@sx2008
Für alle Projekte mit Zukunft kann ich Dir nur zustimmen. Zitat:
Zitat:
Allerdings habe ich es schon erlebt, das sowohl XML als auch CSV durch editoren und Excel massakriert wurden. Zitat:
Um Deine erste Aussage noch einmal aufzugreifen, wir betreiben hier "Datenverarbeitung" und da sollten wir Daten auch mit größtmöglicher Sorgfalt behandeln. Gruß K-H |
AW: Darf man "File of <Record>" noch benutzen?
Zitat:
Ein Kunde exportiert z.B. regelmässig seinen Kundenstamm in dieses fixed record format und importiert es dann mit einer anderen Software in eine Datenbank. Durch Änderungen in seiner IT ändert sich der Zeichensatz von ISO 8859-1 auf UTF-8. Er hat den Import zwar getestet, nur waren halt keine Umlaute in den Testdaten. Im Echtbetrieb sind aber Umlaute enthalten (UTF-8 Multibytezeichen) und schon verschiebt sich alles. Oder seine Daten stammen aus einem Unix-System und werden per FTP in die Windowswelt kopiert. Dabei wird auch der Zeilenumbruch von CR --> CR/LF umgewandelt. Aber einmal nicht aufgepasst (weil binary statt text-Mode verwendet) und alle Records sind um ein Zeichen zu kurz was "wunderhübsche" Datenverschiebungen zur Folge hat. In der Importsoftware haben wir dann eine Prüfung eingebaut:
Delphi-Quellcode:
Das gab aber auch wieder Ärger denn abundzu kam es vor, dass hinter dem letzten Record noch ein End-Of-File Zeichen klebte.
if FileSize mod RecordSize <> 0 then Fehler()
|
AW: Darf man "File of <Record>" noch benutzen?
Zitat:
Stopp... Doch Du hast in alles Punkten recht...Nicht weiter lesen... Wenn man eine Software programmiert, die Dateien bearbeitet, die ein User in irgend einer Form mit anderer Software auch bearbeiten können muss... Aber [OT] Ich will nicht, dass: 1. Meine Anwender auch nur die Möglichkeit haben die Dateien zu editieren. 2. Dritte in die Dateien reinschauen können. 3. Kompatibilität zu Vorgänger-Versionen herzustellen ist. 4. --- Punkt gestrichen --- Daher werden alle Daten-Dateien Verschlüsselt, mir jeweils anderer Reihenfolge pro Programmstart gespeichert, jeweils mit anderem Offset versehen, die Verschlüsselung ändert sich per Zufall usw. Querbeziehungen stellen eine Manipulation fest, redundante Speicherung verhindert Datenverlust. Und alles was mir in den letzten 31 Jahren noch so eingefallen ist. [/OT] Mavarik PS: Unnötig zu erwähnen, dass es nix schnelleres gibt als ein Blockread... Wenn die Datensatzlängen dann noch glatte Sektorgrößen/Binärlängen haben...Und der Lesepuffer so viele Daten aufnehmen kann wie die Festplatte in einer Umdrehung lesen kann.... PPS: Achja, dass waren noch Zeiten, als man den Floppy-Controller und die DMA noch per ASM angesprochen hat. |
AW: Darf man "File of <Record>" noch benutzen?
Zitat:
Zitat:
Wartbarkeit, Erweiterbarkeit, Robustheit sind die Schlagworte. Wenn das alles gewährleistet ist, kannst Du über Performance nachdenken. Oder wenn Du ein RDBMS schreibst, oder einen Datenlogger, von mir aus. Die gängigen und modernen Dateiformate und Bibliotheksfunktionen sind eh schnell genug und fast immer wartet die Anwendung auf den Anwender und nicht umgekehrt. Ich mache mir jedenfalls keine Gedanken mehr über Probleme, die vor 30 Jahren schon gelöst wurden. Zitat:
Wenn mir ein altes 'File-Of-Record' über den Weg läuft, welches ich lesen muss, dann drücke ich jedes Mal die Daumen, ob die Feldausrichtung der Recordelemente immer noch genau so ist, wie damals. Das Problem hat man ja -nebenbei bemerkt- nicht nur bei Dateien, sondern leider werden auch viele Daten so verschickt. Ich gehe mittlerweile so vor, das ich Element für Element einzeln aus dem Stream fische. So kann ich padding Bytes, Endianverknurpselungen oder sonstige exotische Dateitypen individuell abfangen. Wenn ich Objekte serialisiere (was einem File-Of-Record ähnlich ist), dann bekommen meine Objekte eine Versionsnummer. Die steht in jedem 'Record' als erstes. Anhand dieser Nummer kann ich dann entscheiden, wie ich vorgehe und welche Eigenschaften in welcher Reihenfolge gelesen werden. XML finde ich persönlich grauslich, aber nur, weil die Datei 'ein wenig' größer wird, als beabsichtigt. Ansonsten ist es idiotensicher und eignet sich auch zum Austausch mit Daten aus der inneren Mongolei. Hier ist JSON für mich geeigneter, weil es genauso idiotensicher ist, aber eben kompakter. Um die Frage des TE zu beantworten: Man darf, wenn man muss, aber man sollte nicht, wenn man die Wahl hat. |
AW: Darf man "File of <Record>" noch benutzen?
Zitat:
|
AW: Darf man "File of <Record>" noch benutzen?
Einige der Hauptgründe für ein file of record sind doch wohl,
|
AW: Darf man "File of <Record>" noch benutzen?
Bekanntermaßen führen viele Wege nach Rom. Und die o.g. Anforderungen lassen sich mit typisierten Dateien prinzipiell natürlich erreichen. Auf die möglichen Probleme, die dieser Weg mit sich bringen kann, wurde ja schon völlig richtig hingewiesen. Wenn es wichtig sein sollte - warum auch immer - punktuell nur einzelne Bereiche einer Datei zu beschreiben, dann können typisierte Dateien wieder hoch im Kurs stehen.
Letztlich ist auch "File of Record" nur eines von mehreren Werkzeugen der Softwaretechnik und man wird in Abhängigkeit der Anforderungen seine Wahl treffen müssen. |
AW: Darf man "File of <Record>" noch benutzen?
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:28 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