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

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

[Mavarik]

Zitat von Daniel:

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.

Diplomatisch wie immer...

Und natürlich hast Du 100%ig Recht!

Mavarik

[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

[p80286]

Zitat von Furtbichler:

Wartbarkeit, Erweiterbarkeit, Robustheit sind die Schlagworte. Wenn das alles gewährleistet ist, kannst Du über Performance nachdenken.

Das merkt man einigen Programmen an. Die sind so mit dem Suchen einer möglichen Erweiterung beschäftigt, daß für ihren eigentlichen Zweck nichts mehr übrig bleibt.
Grundsätzlich hat ein Programm seine Arbeit so schnell es geht zu erledigen, und dabei immer nach dem alten Motto "First make it run, then make it fast"

Gruß
K-H

[Furtbichler]

Zitat von p80286:

Grundsätzlich hat ein Programm seine Arbeit so schnell es geht zu erledigen

Äh. In der professionellen Softwareentwicklung eher nicht, denn da erntest Du mit dieser Aussage Hohn, Spott und abfälliges Schmunzeln.

Zitat von gammatester:

Kann mir jemand erklären, wie man diese Anforderungen erreicht

Datenbank, fällt mir auf Anhieb ein. SQLite, Access. Was kleines eben. Ich wähle meine Werkzeuge anhand der Anforderung. Wenn ich wahlfreien Zugriff benötige (mit Sicherheit über einen Schlüssel), nehme ich eine DB.

Zitat von Sherlock:

Nicht nur Deine Entwicklung schützt du damit. Der Support-Aufwand hält sich in Grenzen wenn Anwender nicht in Daten rumwurschteln können

Ich weiss ja nicht, was für und welche Daten ihr da in so einem File-Of-TIrgendwas verschlüsselt abspeichert, aber bei mir ist das so: Eine Liste kommt in eine DB, Konfigurationseinstellungen in eine XML/INI usw.

Ich hatte bisher erst einen Fall, bei dem die Daten geschützt sein mussten. Dann wird eben verschlüsselt. Aber nur, weil es sich um einen embedded PC handelte, ohne Netzanbindung und keinerlei DB-Treiber installiert werden durften. Ansonsten schütze ich Daten, indem sie auf das RDBMS kommen.

Übrigens würde ich mich freuen, wenn irgendwer in Konfigurationsdaten rumfummelt. Das gibt nämlich dann eine saftige Rechnung!

Ich kenne nur keinen Fall, wo ich File-of-record einem Stream vorziehen würde. Aber vermutlich, weil ich nicht mit Records arbeite, keine Shortstrings verwende, sowie keine einfachen Strukturen habe.

Jedem das Seine, würde ich da sagen.

[Sir Rufo]

Irgendwie habe ich diesen Thread so verstanden, dass Daten von einem alten Delphi-Programm eingelesen werden sollen.

Im neuen Programm würde ich auch auf aktuelle Strukturen setzen (Datenbank, XML, etc. bzw. Klassen statt Records) aber den Zugriff auf diese alten Daten mit einem Adapter-Pattern und dem file of record (in einem Strategy-Pattern) realisieren.

[Der schöne Günther]

Richtig, eigentlich wollte ich nur wissen, ob ich Legacy-Daten, die ebenso geschrieben wurden, auch wieder so einlesen kann. Ob das Konzept mit dem "File" heute Probleme bei Dingen wie Rechten, Netzwerkpfaden, Überschreitung von Dateigrößen oder Sonderzeichen mit sich bringt.

Aber ein bisschen weiterführende Diskussion schadet ja nicht