Darf man "File of <Record>" noch benutzen?

[sx2008]

Zitat von Der schöne Günther:

Da nehme ich es ehrlich gesagt auch gerne dankend an, wenn ich eine Zehnerpotenz Speicher sparen kann...

Da hat CSV durchaus Vorteile weil anhängende Leerzeichen nicht mitgespeichert werden.
Wie gesagt man muss Vor- und Nachteile gegen einander abwägen.
Ein Format mit festen Records hat da einfach zu viele Nachteile.

[Blup]

"File of <Record>" ?
Wenn es wirklich auf große Datenmengen und Geschwindigkeit ankommt, sind "Memory Mapped Files" die bessere Lösung.

[p80286]

@sx2008
Für alle Projekte mit Zukunft kann ich Dir nur zustimmen.

Zitat von sx2008:

Nach "Word 97" kräht heute kein Hahn mehr aber *.doc Dateien die mit dieser Version erzeugt wurden können immer noch wichtig sein.

Auch damals gab es schon RTF, aber dafür hätte man Benutzer schulen müssen.

Zitat von sx2008:

Änderungen mit dem Editor sind gefährlich und können die Struktur zerstören.
Im Worstcase kann die ganze Datei zum Datensalat werden.

Insbesonders wenn der Editor Blanks zu Tabulatoren macht, und noch ein zweiter in Spiel kommt, der die umgekehrte Übersetzung mit einer anderen Anzahl blanks durchführt.

Allerdings habe ich es schon erlebt, das sowohl XML als auch CSV durch editoren und Excel massakriert wurden.

Zitat von sx2008:

Oder man Importiert eine Datei mit 40000 Datensätzen in die Datenbank und stellt dann fest, dass alle Felder um ein Zeichen verschoben sind.
Dann ist guter Rat teuer - wie bekommt man die defekten Datensätze wieder aus der Datenbank heraus?

So etwas kommt vor, aber das liegt vielleicht auch ein wenig am oberflächlichen Umgang mit den vorhandenen Daten?

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

[sx2008]

Zitat von p80286:

Zitat von sx2008:

Oder man Importiert eine Datei mit 40000 Datensätzen in die Datenbank und stellt dann fest, dass alle Felder um ein Zeichen verschoben sind.
Dann ist guter Rat teuer - wie bekommt man die defekten Datensätze wieder aus der Datenbank heraus?

So etwas kommt vor, aber das liegt vielleicht auch ein wenig am oberflächlichen Umgang mit den vorhandenen Daten?

Ich sehe die Schuld mehr beim Datenformat.
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: if FileSize mod RecordSize <> 0 then Fehler() Das gab aber auch wieder Ärger denn abundzu kam es vor, dass hinter dem letzten Record noch ein End-Of-File Zeichen klebte.

[Mavarik]

Zitat von sx2008:

Also in der profesionellen Softwareentwicklung darf man eigentlich "File of <Record>" nicht mehr benützen und ich möchte das auch begründen.

Oje... Unnötig zu erwähnen, dass ich Dir eigentlich in keinem Punkt zustimmen kann...

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.

[Furtbichler]

Zitat von Mavarik:

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]

Ist das dein Ernst? Wo sind die Ironie-Tags?

Zitat:

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

Ich weiss nicht, in welchem Jahrhundert Du lebst, aber erstens gibt es schnelleres als ein Blockread (ReadFileGather, MMF usw.), zweitens macht Dir deine Win-API mit ihrer Systempage einen Strich durch die Rechnung und drittens kräht im 21.Jahrhundert kein Hahn mehr primär nach Performance.

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:

PPS: Achja, dass waren noch Zeiten, als man den Floppy-Controller und die DMA noch per ASM angesprochen hat.

Gott-Sei-Dank sind die vorbei und man muss nicht mehr in der Buddelkiste Häuschen bauen sondern kann mit ausgereiften Werkzeugen Städte konzipieren und errichten (lassen).

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.

[jaenicke]

Zitat von Furtbichler:

XML finde ich persönlich grauslich, aber nur, weil die Datei 'ein wenig' größer wird, als beabsichtigt.

Es gibt ja bereits einige weit verbreitete Formate, angefangen bei den beiden großen Office-Formaten, die die XML-Daten gezippt speichern. Damit hat man die Metainformationen des XML-Formats zusammen mit relativ kleinen Dateien und kann zudem Inhalte wie Bilder auch gleich geordnet mit speichern, falls erforderlich.

[gammatester]

Einige der Hauptgründe für ein file of record sind doch wohl,

• man hat Randomaccess auf einzelne Records ohne Indexdateien (man eine Datei etc),
• man kann einzelne Records ändern und an die gleiche Position zurückschreiben (ohne den Rest der Datei zu ändern, diese zu kopieren erc),
• man kann für einzelne Records Checkdaten (zb CRC) einfach berechnen, ändern und verifizieren,
• ...

Kann mir jemand erklären, wie man diese Anforderungen erreicht, wenn man die Daten als Text serialisiert (womöglich noch Compiler abhängig), sie dann aber vielleicht noch zippen muß, weil die Datenmenge dann doch überraschenderweise etwas zu groß wird.

[Daniel]

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.

[Der schöne Günther]

Zitat von Furtbichler:

Hier ist JSON für mich geeigneter, weil es genauso idiotensicher ist, aber eben kompakter.

Kleine Anekdote am Rande: Es war immer wieder lustig, wenn Delphi in der Serialisierung nach JSON Fließkommazahlen mit Kommas ausgespuckt hat. Was dann mit einem JSON-Stream passiert kann man sich vorstellen . Nicht ganz so idiotensicher wie XML würde ich sagen