hallo

ich möchte daten auf der festplatte in einem file speichern. im moment sind es ne menge einzelner textfiles.
leider hab ich sowas noch nie gemacht und suche einen ansatz für die aufteilung im textfile... wie navigiert man ? wie unterteilt man blöcke die man wiederfindet und auslesen kann und solche sachen...? verschlüsselung/komprimierung - ja/nein?
gibts vielleicht units mit klassen für soetwas, wo schon alles implementiert ist, so dass man selbst nicht mehr mit filestreams und anderem konfrontiert wird ? vielleicht auch mit guter performance !?

was könnt ihr mir empfehlen ?


Moderiert von Gausi: Topic aus Sonstiges (Delphi) verschoben am Mo 08.09.2008 um 13:33

Da du das Navigieren innerhalb der Datei ansprichst: Wahrscheinlich am Besten/Einfachsten lösbar mit einer Datenbank oder über XML...

Gruß
--

hi,

was spricht gegen filestreams? vlt sind inifiles was für dich? ansonsten werden alle units, die du findest, auf filestrems aufbaun...

FileStreams (bzw. Streams allgemein) sind nicht so kompliziert, wie sie am Anfang aussehen. Das evtl. größere Problem ist, sich ein geeignetes Format für die Daten zu überlegen. Wenn du mehrere "Datenblöcke", d.h. Textdateien in eine Datei packen willst, wäre wohl das einfachste, zuerst die Dateigröße der ersten Textdatei/Datenblocks in den Stream zu schreiben, dann die erste Textdatei selbst, dann die Größe der zweiten usw.

Über die Größenangaben kannst du dich dann durch die Datei hangeln und den gewünschten Teil auslesen.

also ini files sind glaub ich nichts für meinen bedarf. das datenfile wäre unkomprimiert wenn die dateien so drin stehen wie im moment in den txt files um die 5gb groß...

edit: die files haben alle die gleiche anzahl von zeilen haben, wäre es dann nicht einfacher mit delimitern zu arbeiten !?
gibts dazu ein tutorial ? filestream mit delimitern oder eine unit die z.b. stringlisten in einer datei speicher kann und sie selbst formatiert, so dass man selbst z.b. nur sagen muss welche stringlist man will und die unit navigiert einem in dem datenfile zur gewünschten position oder liefert die stringlist zurück ?

Was sind denn das für Daten? Sind das überhaupt Textdaten, für die eine Speicherung in einer Textdatei sinnvoll ist?

also das beste wäre ne db wie sql oder so, aber es soll auf jedem pc benutzbar sein ohne schnickschnack wie ein mysql server oder sowas.

in sofern wäre es nur als datei sinnvoll, denn 50k txt dateien einzeln zu öffnen und wieder zu schließen nimmt viel performance! oder gibts andere möglichkeiten ? alles in den ram zu packen scheidet aus bleibt nur noch hd, ist nur die frage nach dem format...
und xml ist auch zu lahm bei den mengen die ich hier an daten habe.

Naja, es ist ziemlich schwierig eine 5gb-Große datei zu öffnen (geht mittels paging, aber extrem langsam), deshalb ist es wohl doch eine bessere Lösung, dass aufzutrennen.

Wieso ist das schwierig, eine 5GB Datei zu öffnen? Man muss ja nicht alles auf einmal in den Speicher lesen. Wenn die Datei ordentlich strukturiert ist, kann man in der Datei die gerade interessanten Stellen suchen, auslesen und verarbeiten.

Aber ohne weitere Informationen kann man da kaum was zu sagen...

Was du machen könntest wäre ein Inhaltsverzeichnis an den Anfang zu schreiben.

Also vorher gucken wie groß die Dateien sind und dann die Größen der Dateien und Positionen in deiner neuen Datei im Inhaltsverzeichnis zu sichern. Die anderen Dateien kommen dann einfach dahinter.

So kannst du direkt an die stellen in der Datei springen und brauchst nicht erst die ganze Datei zu lesen, sondern nur das Inhaltsverzeichnis. Die Größe ändert sich so natürlich nicht, dafür könntest du die Daten erst packen (ZIP?) und dann in deine Datei packen.

Es gibt auch embedded DBs, wie z.B. SQLite, aber ob die (gut) mit >5GB großen Datenmengen auskommen, weiß ich nicht.

baka0815 hat folgendes geschrieben:

Die Größe ändert sich so natürlich nicht, dafür könntest du die Daten erst packen (ZIP?) und dann in deine Datei packen.

Ich lasse mich ja gerne eines besseren belehren, aber bei mir dauert es selbst mit sevenzip einige Zeit, grosse Dateien zu entpacken. (t>1h)

Deswegen ja nicht das gesamte Archiv packen, sondern nur die einzelnen Dateien darin.

Ist zwar größer als wenn man alles zusammen archivieren würde (zumindest bei soliden Archiven), aber bestimmt kleiner als ohne Komprimierung.

Ich meine das so:

[Inhaltsverzeichnis][Datei1][Datei2][Datei3]...[DateiN]

Wobei [Datei1], etc. bereits gepackt sind, es muss also immer nur die benötigte Datei entpackt werden.

Alternativ kann man natürlich die ganzen Dateien in eine Datei packen, dabei aber auf keinen Fall(!) ein solides Archiv erstellen, und dann die benötigten Dateien einzeln entpacken - spart die multiplen ZIP-Header und die eigene Implementierung eines Inhaltsverzeichnisses. Da man in nicht-soliden Archiven die Dateien einzeln entpacken kann, sollte das nicht so lange dauern.

Kommt aber drauf an, ob es sich um viele kleine Dateien handelt, die zusammen eine große Datei bilden (dann macht mein oben beschriebener Ansatz, die Dateien einzeln zu packen, keinen Sinn) oder ein paar große Dateien.

mit inhaltsverzeichnis vorne und dateien dahinter gefällt mir gut.
nur wüsste ich jetzt nicht wie ich das mit filestream bewerkstelligen sollte.