Stringgrösse in einem Record ändern

[dummzeuch]

Jemandem als Alternative zu einem File of Record JSON oder XML zu empfehlen, ist mutig. Die Performance geht dann deutlich in den Keller, wenn es um mehr als eine Handvoll Records geht.

[jaenicke]

Das stimmt natürlich.

[Uwe Raabe]

Ich bin mir auch nicht sicher ob human readable überhaupt wünschenswert oder gar notwendig ist. Das bedeutet nämlich immer auch human writable und erschwert die Plausibilitätskontrolle beim Einlesen beträchtlich.

[Delphi.Narium]

Wie wäre es mit 'ner Memorytable? Da kann man nachträglich die Größe von Stringfeldern problemlos nach oben (ohne Datenverlust) verändern. Man kann sie als Datei speichern und natürlich auch wieder einlesen und als "Schmakerl" obendrein wie 'ne Datenbanktabelle ansprechen.

Zitat:

Zitat von Uwe Raabe (Beitrag 1541605)

Ich bin mir auch nicht sicher ob human readable überhaupt wünschenswert oder gar notwendig ist. Das bedeutet nämlich immer auch human writable und erschwert die Plausibilitätskontrolle beim Einlesen beträchtlich.

Da kann man ja dann 'ne verschlüsselte Datenbank nehmen. Oder die XML, JSon, ... in 'ner verschlüsselten ZIP speichern, ...

Und wenn bisher ein Record gespeichert wurde, ist das sicherlich human readable, man muss ggfls. nur einmal die einzelnen Werte im Record analysieren. Damit kann man dann auch recht problemlos DBase-Dateien (o. ä.) lesen. Header + feste Satzlänge. Bei Records halt "nur" feste Satzlänge.

[dummzeuch]

Zitat:

Zitat von Delphi.Narium (Beitrag 1541606)

Und wenn bisher ein Record gespeichert wurde, ist das sicherlich human readable, man muss ggfls. nur einmal die einzelnen Werte im Record analysieren. Damit kann man dann auch recht problemlos DBase-Dateien (o. ä.) lesen. Header + feste Satzlänge. Bei Records halt "nur" feste Satzlänge.

Die wenigsten trauen sich, binäre Dateiformate zu editieren. Aber bei Textdateien ist die Hemmschwelle deutlich geringer und vor allem sehen sie darin auch kein Problem, denn es ist ja Text.

[Delphi.Narium]

Naja, wenn ich mir so manche JSon anschaue, dann traue ich mich da aber auch nicht mit dem Editor dran. Man kann sie quasi deutlich lesbar uneditierbar machen. Einfach mal nur 50 MB als Einzeiler ;-) Bei XML kann es sehr ähnlich zugehen. Oder wenn man sich so manche HTML-Seite ansieht, was die Browser da leisten müssen, um was lesbares daraus zu erstellen, das ist schon heftig.

Da erscheinen mir Dateien, in denen einfach Records mit fester Länge hintereinandergeschrieben werden, schon beinahe als deutlich einfacher zu manipulieren ;-)

Und nein, wirklich sicher geht nicht, die Frage ist nur, mit welchem Aufwand kann man an die Daten ran und lohnt der Aufwand dann noch.

Da wir nicht wissen was für Daten hier konkret gespeichert werden und wie "sicher" sie sein müssen, kann es durchaus unkritisch wein, wenn die Daten nicht manipulationssicher sind.

[dummzeuch]

Zitat:

Zitat von Delphi.Narium (Beitrag 1541608)

Naja, wenn ich mir so manche JSon anschaue, dann traue ich mich da aber auch nicht mit dem Editor dran.

Du schon, aber Du weißt, dass JSON nicht zum Editieren durch User gedacht ist und welche Folgen es haben kann, wenn man das Format kaputt macht. Der typische User weiß das nicht.

Zitat:

Zitat von Delphi.Narium (Beitrag 1541608)

Da erscheinen mir Dateien, in denen einfach Records mit fester Länge hintereinandergeschrieben werden, schon beinahe als deutlich einfacher zu manipulieren ;-)

Und nein, wirklich sicher geht nicht, die Frage ist nur, mit welchem Aufwand kann man an die Daten ran und lohnt der Aufwand dann noch.

Da wir nicht wissen was für Daten hier konkret gespeichert werden und wie "sicher" sie sein müssen, kann es durchaus unkritisch wein, wenn die Daten nicht manipulationssicher sind.

Mir ging es dabei weniger um "manipulationssicher" sondern um (nicht nachvollziehbare) Programmfehler, die dadurch entstehen, dass User scheinbar "einfache" Textdateien verändern.