Daten speichern

[Urba]

Hallo Leute,

Ich möchte aufgrund meines Auslagerungsdateienproblems (siehe Thread weiter unten) nun umsteigen auf selbst geschriebene binäre Dateien die ich dann wie eine DB nutze. Ich hab mir nun zu den einzelnen Datentypen schon ein paar Sachen überlegt aber es stockt noch bei den meist genutzten. Den Typ Byte kann ich ja ohne weiteres in EINEN Byte schreiben. Bei Integer, Double usw (also sowohl ganzzahlige wie auch mit Kommastellen) hab ich da schon eher ein Problem. Ich wollte sie eigentlich recht platzsparend abspeichern, also nicht unbedingt als String o.ä. Hat da einer eine Idee von euch wie das System das macht ? Ach und nochwas : Bitte keine Vorschläge bezüglich typisierten Dateien, DBs o.ä. weil ich mir frei halten will wie ich MEINE dateien bearbeite und auch nichts mitliefern möchte. Daher und aus Übungsgründen möchte ich eigene Dateitypen erstellen.

Danke schonmal für eure Antworten

Gruß
Urba

[GuenterS]

Hallo,

es ist schon klar, dass man Zahlen nicht als String speichert, es sei denn sie sollen "lesbar" sein.

Ein Integer würde also 4 Byte belegen, ein Cardinal ebenso.

Was genau stört Dich denn an typisierten Dateien?

Du könntest deine Daten natürlich auch in einen Stream schreiben, wo Du weißt wie sie aufgebaut sind. Bei den Zahlentypen ist die Länge ja schon vorher bekannt, wenn Du Strings also Zeichenketten speichern möchtest, solltest Du vorher noch die Länge reinspeichern, sonst weißt Du beim Lesen nicht, wie lang der nun war.

[Urba]

Hi,

Hatte es jetzt eigentlich so geplant, dass ich mit BloadRead, Write, Rewrite usw. mir einfach meine Datei "zusammenkloppe" Wenn mir jemand ein beispiel zu etwas gleichwertigem geben kann ist er sehr willkommen. Meine Erfahrungen mit typisierten Dateien reichen eigentlich nicht sehr weit. Dachte immer da kann man nur einen Array oder so auslagern und dann auch nur einen statischen, stimmt das ?

Dass ein Integer 4 Bytes lang ist ist mir schon klar, aber wie speichert das system einen integer ?

Gruß
Urba

[GuenterS]

Ich würde Dir einen FileStream empfehlen. Da kannst Du nacheinander das reinschreiben was Du möchtest und bist nicht an eine bestimmte RecordStruktur gebunden ... Vorrausgesetzt Dein einlesender Part weiß was er wie zu lesen hat.

Delphi-Quellcode:

...
   var
     lFileStream: TFileStream;
     i: integer;
     lStr: string;
   begin
      lFileStream := TFileStream.Create('C:\Testfile', fmCreate);
      try
         lStr := 'Das ist ein String';
         i := length(lStr);
         lFileStream.WriteBuffer(i, sizeOf(i));
         lFileStream.WriteBuffer(PChar(lStr)^, i);
      finally
         lFileStream.Free;
      end;
   end;
...

Da wird zuerst die Länge des Strings und anschließend der String selbst in die Datei gespeichtert. Der auszulesende Teil muss also wissen, dass er zuerst die Länge und dann darauf basierend den String lesen soll.

[vlees91]

EDIT: Das ist im prinzip das gleiche wie oben, nur dass hier das dateiformat (die richtlinien) definiert wurden und ich es so einfach finde schnell sachen an dateien zu ändern, da ja alles automatisch gemachtr wird mit nur einem readstream
EDIT2: die TDBFile kann natülich noch in andere typen eingeteilt werden. zum beispiel TDBFileHeader und TDBFileContent oder so ähnlich

Delphi-Quellcode:

type
  TDBFile = packed record
    Signature : array [0..024] of char;
    wert : integer;
//und so weiter
  end;

dann liest man so

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var
  ReadStream : TFileStream;
  ReadSize, size : Int64;
  DBFile : TDBFile;
begin
    ReadStream := nil;

    ReadStream := TFileSTream.Create('dbdatei.format', fmOpenRead);
    size := ReadStream.Size;
    ReadSize := 0;
      
    ReadStream.ReadBuffer(DBFile, sizeof(TDBFile));
    //in DBFile.Signature steht dann die Datei signatur in DBFile.wert steht dann der Integer (4 bytes)
    //so braucht man sich nicht um die byte werte zu kümmern
    //schreiben geht auch so
    //man muss nur die datei mit schreibrechten öffnen und dann mit WriteStream arbeiten
      
end;

ich hoffe dir hilft das

[GuenterS]

Stimmt schon, hat auch seine Vorteile, die aber dann dahin sind, wenn Du eine Anforderung hast etwas in die Datei zu speichern was nur einmal vorkommt. Klar du kannst es Record für Record mitspeichern und damit die Datei unnötigerweise aufblähen.

Es kommt halt darauf an was der Threadersteller eigentlich wirklich will. Er schließt Datenbanken und Typisierte Dateien aus (warum auch immer).

[vlees91]

Zitat von GuenterS:

Er schließt Datenbanken und Typisierte Dateien aus (warum auch immer).

1.

Zitat von Urba:

aus Übungsgründen möchte ich eigene Dateitypen erstellen.

2. ist doch egal
wenn er es so machen will, wie ich es mir vorstelle, dann erscheint mir ein record mit einem array an datensätzen praktisch.
das beispiel mit dem integer war ja nur als BEIPSIEL

[Urba]

Hi,

vlees91 hat mich ja schon gut erklärt Zu meiner Begründung, ich will keine DB weil es mich nervt was man immer mitnehmen muss wenn das Programm weitergegeben wird (ja es gibt auch sowas wie Firefox) aber ich habe gerne selbst die Kontrolle über meine Daten. Bisher warem es Textdateien die komplett in Arrays geladen wurden und irgendwann ist mir aufgefallen dass meine Auslagerungsdateien "etwas" groß wurden (2 GB). Deswegen möchte ich das nun selbst verwalten. Ich will die Zahlenwerte aber nicht unbedingt als String oder ähnliches speichern, so wie weiter oben meiner Meinung nach beschrieben. Ich will wirklich nur die 4 Bytes verwenden um ihn zu speichern ?!

Gruß
Urba

[Der_Unwissende]

Hi,

ich würde dir eigentlich auch immer zu einem Stream raten. Die sind einfach mal recht schnell, auch wenn man das sicher auch mit anderen Mitteln hinbekommt. So richtig flink wird ein TMemoryStream wenn du auf sein Property Memory mittels Win-API zugreifst, aber (genug abgeschweift), ich glaube das ist wohl nicht wichtig.

Ja, jedenfalls kannst du so ziemlich alles was du in eine Datei schreiben möchtest auch als Array von Bytes interpretieren. Musst halt immer nur wissen wieviel Byte das hat was du als nächstes lesen möchtest.
Mit einem Datentypen TByteArray = Array of Byte kannst du dann beliebige Daten laden und entweder mittels shift und and wieder zusammensetzen oder halt die selbe Menge von Bytes in Teilen anders interpretieren (ist halt etwas casten angesagt).
An sich kann ich dir als Idee für ein eigenes Dateiformat nur dazu raten, dir mal die Tiff-Spezifikation an zu sehen. Kannst du ja für deine Zwecke entsprechend abwandeln, aber die Idee finde ich eigentlich super (sorry falls andere die auch oder vorher hatten, kenn sie erst seit Tiff).
Da gibt es einen fest header, der mit einem Offset auf sogenannte IFDs (ImageFileDirectorys) endet. Diese IFDs sind wirklich Einträge a la Inhaltsverzeichnis und bestehen immer aus einem Tag, der das Feld identifiziert (z.B. Höhe oder Breite), einem Tag der den Datentypen (String, Integer, Byte, ...) beinhaltet, die Anzahl von Elementen und zuletzt den Wert bzw. wenn größer als 32 Bit dann einen Offset zu der Position der Daten.
Klingt vielleicht etwas kompliziert und umständlich, aber so kannst du leicht flexibel bleiben und deine Datei erweitern. Grundregel ist halt, dass alles rein kann und du nur Felder auswerten brauchst, deren Identifizierung dir/deinem Reader schon bekannt ist.

Also für den eigentlichen Zugriff kann ich dir wie gesagt auch nur Streams empfehlen.

Gruß Der Unwissende

[vlees91]

so wie in meinem beispiel sinds ja dann nur die 4 bytes
die "signature" war nur als beispiel, dass man direk noch andere sachen reinschreiben kann und die dann auch noch richtig wieder ausgelesen werden.
die "signature" kann auch weggelassen werden und dafür noch 20 integers reingesetzt werden oder 1000 integers
oder agnz am anfang einer datei steht ein integer mit der anzahl der weiteren integers
dann wird ein array aus integer in der TDBFile geändert und dann wirds eingelesen
dann hat man auch eine dynamische dateigröße...