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

[p80286]

Kleine Anmerkung, ich arbeite mit einem buffer der x*sizeof(rec) ist, da läuft dann immer ein Lesezeiger mit. Ist etwas schneller als jeden record einzeln zu lesen.
Schreiben habe ich allerdings (noch) nicht implementiert.

@Der schöne Günther
Was Du suchst ist IORESULT.

Gruß
K-H

[Mavarik]

Natürlich darf man das...

Nutze ich "nur"...

[e-mail]

[jaenicke]

Zitat von Aro:

aber es ist schnell und sicher.

Aber deutlich langsamer als z.B. MMFs zu benutzen. Die vielen kleinen Zugriffe machen das ganze insgesamt sehr langsam, wenn es größere Datenmengen sind.

[sx2008]

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

1.) der Datei fehlt jeglicher Hinweis auf die enthaltene Datenstruktur
Da aber Daten wichtiger sind als Programme ist dies ein Problem.
Nach "Word 97" kräht heute kein Hahn mehr aber *.doc Dateien die mit dieser Version erzeugt wurden können immer noch wichtig sein.
2.) fehlende Interoparatibilität mit Fremdsoftware.
CVS oder XML-Formate können auch mit anderer Software ausgewertet werden;
ein "file of <Record>" ist ein totes Gleis
3.) fehlende Robustheit gegen Programierfehler und Wechsel der Programmiersprache
Sollte der Programmierer bei der Definition des Record ein Fehler gemacht haben oder soll die Software in andere Progsprachen portiert werden kann es zu Verschiebungen kommen.
Änderungen mit dem Editor sind gefährlich und können die Struktur zerstören.
Im Worstcase kann die ganze Datei zum Datensalat werden.

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?
4.) fehlende Erweiterbarkeit
Soll ein Feld vergrössert werden, dann gibt es Schwierigkeiten.
Die Software muss die alte und die neue Struktur beherrschen und ausserdem muss sie wissen ob eine best. Datei die alte oder schon die neue Struktur hat
5.) hoher Dokumentations- und Kommunikationsaufwand
Bei einer CSV-Datei muss man nur die Reihenfolge der Felder und dessen Bedeutung kennen.
Beim "file of <Record>" muss jedes Detail fehlerfrei geklärt sein.
Für jedes Feld Position & Länge, Datentyp und bei Strings die Info ob links- oder rechtsbündig.
Mit CR/LF als Recordtrenner oder ohne Recordtrenner, welcher Zeichensatz?
6.) keine Info welcher Zeichensatz benützt werden soll (CSV und XML können dagegen einen BOM verwenden)

Die Vorteile der einfachen Implementierung und des fehlenden Overheads in der Datei können die Nachteile nicht ausgleichen.

Ich und meine Kollegen haben lange Zeit mit "file of <Record>" Dateien gearbeitet.
Wenn uns heute so eine Datei über den Weg läuft wird geflucht, nach der Doku gesucht (manchmal gibt es keine) und der Taschenrechner wird zum wichtigsten Hilfsmittel.

[Namenloser]

Ich wüsste wirklich nicht, wieso irgendjemand noch die alten Pascal-Routinen verwenden wollen würde, wo es Streams gibt... Ich fand das Arbeiten mit Streams schon immer viel angenehmer und intuitiver. Streams haben außerdem den Vorteil, dass du von jeder Datenquelle einlesen kannst, also nicht nur von der Festplatte, sondern auch aus dem RAM (TMemoryStream) oder ganz woanders her, z.B. von einem Netzwerkstream.

Dein obiges Beispiel mit Streams 1:1 übersetzt:

Delphi-Quellcode:

[...]
var
   Stream: TStream;
   returnedData: TSomeRecord;

   [...]
begin
   [...]
   
   try
      Stream := TFileStream.Create(absoluteFileName);
      [...]
      try
         // Hier unnötig:
         //   Stream.Position := 0;
         while Stream.Read(returnedData, SizeOf(returnedData)) > 0 do begin
            [...]
         end;
      except
         // Exceptions gibt es bei Streams natürlich! Z.B.:
         on EReadError do [...]
      end;
   finally
      Stream.Free;
   end;
   
   [...]
end;

Ist sogar eine Zeile kürzer.

Sehr praktisch finde ich bei Streams, dass man das Schreiben der Datei über mehrere Klassen und Methoden verteilen kann. Man übergibt einfach den Stream als Parameter. So kann man z.B. sehr einfach baumartige Objekt-Strukturen abspeichern... und das Wiedereinlesen geht ganz genau so.

Wenn man es einigermaßen schlau anstellt, kann man solche Binärdateien (im Gegensatz zu File of record, wo man an das "record-Raster" gebunden ist) auch erweiterbar gestalten, indem man z.B. vor jeden Datensatz eine Typen-ID und eine Länge schreibt.

Bei diesem Tutorial kann man sich einige Anregungen holen.

[Der schöne Günther]

Vielen Dank für die neuen Antworten!

Meine ursprüngliche Frage ging weniger um die Struktur, ob man neue Daten so speichern sollte - Ich wollte wissen, ob ich Legacy-Daten, die eben so als Flat File auf die Platte geschrieben wurden auch so wieder einlesen kann. Oder ob es etwas besseres gibt.
Das hat NamenLozer ja jetzt bestens geklärt

Auch wenn ich heute menschenlesbare standarisierte Formate wie CSV oder XML einsetze wo es geht: Bei wirklich massenhaftem Datenaustausch der einigermaßen schnell über die Bühne gehen muss bin ich mir da nicht sicher.
Mein Haus liefert bsp. neuerdings auch Systeme aus, die nur noch noch lokal eine SSD haben und Netzanbindung an eine externe DB ist nicht unbedingt gegeben. Über Jahre hinweg fallen da eine Menge Daten an die vorgehalten werden müssen. Da nehme ich es ehrlich gesagt auch gerne dankend an, wenn ich eine Zehnerpotenz Speicher sparen kann...

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