weitergabe und Speicherung von daten

[blinder007]

Hallo Community,
ich will größere Informationen die Außerhalb des Programmes gelagert werden sollen und auf denen, während der Laufzeit, zuggriffen werden soll. Ich überlegte mit typisierten dateien oder mit tfilestream zu arbeiten. Nun sagte mir ein befreundeter Programmierer, es gäbe probleme bei der weitergabe zwischen 16-32 und 64bit rechner, auf grund verschiedener Datentypen. Er riet mir die Informationen in Textdateien zu speichern. Da aber der Anwender nicht auf diese Informationen zu greifen darf halte ich diese für unpraktisch, da Textdateien leicht geändert werden können. Ini-Dateien bieten mir auch nicht die nötige Sicherheit. habt ihr einen rat? Ich könnte natürlich auch eine Unit schreiben, in der ich diese informationen alle direkt speichere, das würde das Programm aber nur unnötig groß machen.
grüße
blinder007

[Der schöne Günther]

"Informationen" ist aber sehr allgemein. Über welche Mengen an Daten reden wir? Muss darauf performant zugegriffen werden können?

Was ist "Anwender darf nicht darauf zugreifen"? Möchtest du dem Endnutzer deine gespeicherten Daten nicht direkt unter die Nase reiben oder muss es verschlüsselt oder zumindest obfuskiert vor ihm verborgen werden?

In Sachen "typisierte Daten" bzw. "File of XYZ": Neulich hatten wir eine interessante Diskussion darüber. Wenn du die Zeit hast kannst du ja mal lesen: http://www.delphipraxis.net/175696-d...-benutzen.html

Da geht es auch um die Technik, also auch die größer/kleiner werdenden Datentypen und Records und undurchsichtige Dateiformate die in fünf oder zehn Jahren keiner mehr versteht.


Lange Rede, kurzer Sinn: Ich bin entweder zu dumm, oder habe zu wenig Infos, um zu wissen was du genau möchtest. Wenn du sagst, dass du die Daten auch im Quelltext ablegen könntest: Dann sind es statische Daten und ändern sich nie? Beispielsweise Lookup-Tables? Wenn wir hier nicht über dutzende Megabytes reden- Warum nicht?

Ansonsten hätte ich spontan eine lokale Datenbank wie SQLite oder einfache XML-Files genommen. Aber vielleicht willst du ja auch etwas ganz anderes machen...

[blinder007]

ich werde mir den thread einmal durchlesen, kingt interessant.
ich versuche dich mal mit weiteren Informationen zu versorgen:
a) es handelt sich dabei um die Datenstruktur eines (oder dann natürlicher vielen, geplant sind ca. 30) records mit ca. 10-15 daten vom typ integer und extended.
b) Es ist möglich, aber unwahrscheinlich, dass die Daten verändert werden müssen, ab einem bestimmten Punkt müssen sie einmal in das Programm geladen werden und an einem anderen Punkt wieder gelöscht / freigegeben werden.
c) es reicht eigentlich das "bloße "nicht unter die nase reiben", - sprich mit der kenntnis über die datenstruktur und dem öffnen einer Datei im editor soll man nicht an der Datenstruktur rumfummeln können (was bei Ini oder txt ja gegeben wäre)
Frage: Ich will mir das arbeiten mit Datenbanken ersparen, habe da schlechte Erfahrungen, deswegen: würde für dateien die in xml erstellt wurden Punkt c zu treffen oder nicht?

Falls es immer noch unklarheiten gibt, bitte Fragen, ich programmiere noch nicht lange, weiß also noch nicht genau welche Informationen relevant sind :)
grüße
Blinder007

[jfheins]

Zitat:

Zitat von blinder007 (Beitrag 1229460)

Würde für dateien die in xml erstellt wurden Punkt c zu treffen oder nicht?

Nein. XML Dateien sind entwickelt worden, um das Datenschema (also was wo steht) explizit mit den Daten zusammen zu speichern.
Einstellungen sehen dann z.B. so aus:

Code:

<?xml version="1.0" encoding="utf-8"?>
<Param xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Kappa>6.7e-6</Kappa>
  <b1>0.1</b1>
  <b2>0.6</b2>
  <Lambda>33.63</Lambda>
  <Epsilon>0.25</Epsilon>
  <Hm>2.75e5</Hm>
  <w0>13.186e-6</w0>
</Param>

Du siehst, man kann da relativ einfach dran herum fummeln. Abhilfe wäre z.B. die Datei nicht "*.xml" zu nennen, sondern eine eigene Endung oder "*.dat". Und vielleicht im Appdata-Ordner speichern, da verirren sich nicht so viele Benutzer hin.

Mit ein Grund für XML ist ja, dass die Daten wichtiger als das Programm sind. Man hatte häufiger mal "uralte Daten, aber verflucht das Programm läuft nicht mehr. Wir brauchen aber die Daten!!!" ;-)

[blinder007]

das klingt interessant, sprich ich speichere meine dateien als xml-files... werde ich mal drüber nachdenken und schauen was hier mit meiner delphi 6 so geht. beim lesen des oben geposteten threads überlegte ich jetzt doch tfilestream zu verwenden, aber da treten dann doch wohl einige Fehler auf.
Was mich dann noch interessieren würde: angenommen ich speichere die records oder klassen in einer xml-file. wie kann ich diese, in der Laufzeit, renamen und delphi zeigen, um welches format es sich handelt, um dann entsprechend damit umzugehen?
Sprich: ich ändere den Dateitypen in .eem (fiktives dateiformat, der user soll es einfach nicht erkennen können), wie kann delphi das als xml-file identifizieren?

[Furtbichler]

Eine Datei umzubenennen, damit die Inhalte nicht verändert werden, ist in etwa so schlau, wie das Schild, auf dem 'Bank' steht, mit einem selbstgeschriebenen Zettel 'keine' zu versehen.

So gut wie jeder wird die Datei nehmen, und mal mit Notepad öffnen. Ich mache das jedenfalls mit jeder mir unbekannten Datei (bzw. Notepad++).

Wie wäre es mit einer einfachen Datenbank, z.B. Firebird? Das zu verändern, dürfte nur mit FB selbst möglich sein und wenn man den Zugriff mit einem Kennwort sichert, wird es noch schwieriger. Unmöglich ist gar nichts, und insofern ist das auch keine perfekte Lösung.

Eine Frage: Darf der Anwender die Dateien nicht verändern, oder willst Du nur mitbekommen, *wenn* er sie verändert hat?

[Der schöne Günther]

Der XML-Inhalt ist im Endeffekt ein langer String. Du kannst die Datei ganz normal mit z.B. einem

Delphi-Quellcode:

TFileStream

öffnen und auslesen. Für Delphi gibt es mehrere XML-Libriaries. Ich benutze XML exzessiv für Speicherung von Konfigurationen und Interprozess-Kommunikation und bin mit dem normalen MS-XML (Klassen IXMLDocument, IXMLNode usw. aus den Units XmlIntf, XmlDoc, ...) eigentlich immer sehr gut gefahren. Ich habe gerade kein Delphi offen, aber die Klasse IXMLDocument hat mein ich bereits eine Methode

Delphi-Quellcode:

LoadFromFile

, da hast du es dann direkt drin, die Dateiendung ist dabei ziemlich egal.

Ob Delphi 6 MSXML schon kennt weiß ich nicht. Vielleicht solltest du die Info in dein Profil eintragen, so sieht man immer, mit welcher Version derjenige unterwegs ist.


@Furtbichler: Die Metapher sehe ich genauso. Nur bei der Häufigkeit, wie oft jemand anfängt in Dateien von Programmen zu wühlen nicht. Wir wissen nicht, was das genau für eine Software ist. Werden damit Waren hergestellt wird früher oder später jemand darin wühlen. Ist es ein Freeware oder in-house Tool für irgendeine Verwaltung oder Visualisierung, dann sicher weniger.
Ich frage mich halt wirklich, ob es denn schlimm ist, wenn jemand das verändert. Wenn er sich damit etwas zerschießt weiß er, dass er selber schuld ist.

Blöd wird die Sache erst, wenn der Kunde dann anruft "Hey, euer Kram funktioniert auf einmal nicht mehr!" obwohl er ihn selbst kaputt gemacht hat. So etwas gibt zu Genüge.

Zitat:

Eine Frage: Darf der Anwender die Dateien nicht verändern, oder willst Du nur mitbekommen, *wenn* er sie verändert hat?

Gute Idee!

[blinder007]

ok, dann hier weitere informationen :)
es handelt es sich um ein, zunächst freeware, später auch shareware, spiel.

In meinem Spiel gibt es auf einer Karte unterschiedliche Städte. Ich will zwei Dateien haben.
Datei 1: enthält die größe der Stadt, die Anzahl der Objekte und Zahlen die diese Objekte identifizierbar machen. in der zweiten datei finden sich dann die ganzen identifizierer, denen dann weitere eigenschaften zugeordnet werden können.

Der User soll nicht in der Lage sein zu erkennen, was sich wo verbirgt oder welche Eigenschaften es hat. gelegentlich soll ein Objekt in einer Stadt zerstört werden, dafür muss aber nicht zwangsläufig der Wert gelöscht werden.
Ist das Prinzip klar?

[Furtbichler]

Dann bleibt nur noch Verschlüsseln. Aber das ist auch Bockmist, weil man das mit Reverseengineering knacken kann.

[BUG]

Zitat:

Zitat von blinder007 (Beitrag 1229474)

es handelt es sich um ein, zunächst freeware, später auch shareware, spiel.

Spieler sind natürlich etwas versierter, denen könnte man auch zutrauen, einen SQLite-Editor oder einen Hex-Editor zu benutzen.
Solange das ein Singleplayerspiel ist, ist das imho aber nicht so tragisch.

An deiner Stelle würde ich mir SQLite auf jeden Fall mal anschauen; eventuell kannst du einige Sachen, die du mit den Daten vorhast, sogar in SQL erschlagen.

Zitat:

Zitat von blinder007 (Beitrag 1229474)

Datei 1: enthält die größe der Stadt, die Anzahl der Objekte und Zahlen die diese Objekte identifizierbar machen. in der zweiten datei finden sich dann die ganzen identifizierer, denen dann weitere eigenschaften zugeordnet werden können.

Das riecht doch schon ein bisschen nach relationaler Datenbank :wink:

Zitat:

Zitat von jfheins (Beitrag 1229465)

Mit ein Grund für XML ist ja, dass die Daten wichtiger als das Programm sind. Man hatte häufiger mal "uralte Daten, aber verflucht das Programm läuft nicht mehr. Wir brauchen aber die Daten!!!" ;-)

Das ist ein wichtiger Punkt. Wenn dein Programm die Daten nur ließt, kannst du die Daten in einem beliebig bekloppten Format ausliefern, solange du die Daten in einem gut dokumentierten Format bei dir gespeichert hast.

[Der schöne Günther]

Aaah, also praktisch eine Karte.

Wenn ich mir die ganzen Spiele anschaue, die über Jahre hinweg erfolgreich waren und sind - Dann konnte der Benutzer immer selbst auch verändern und neues erschaffen. Also eine ganz statische Speicherung im Quelltext haben wir hier wohl vom Tisch.

Wie willst du dann Spielstände organisieren? Ich hätte spontan gedacht, dass ein Spielstand dann ebenso wieder solch eine Karte ist - Wenn beispielsweise etwas zerstört wurde, sich bewegt hat, was auch immer.

Es läuft komplett lokal oder ist es ein Mehrspieler-Spiel? Bei Spielern haben wir wohl eher die Tendenz, dass jemand in den konkreten Dateien wühlt. Ein Spieler ist neugierig 8-)

Ich würde zwar immer noch abwiegen ob man es denn wirklich künstlich unterbinden sollte. Aber: Wenn man es auch nicht lesen können soll, reicht dann nicht, um 95% der potentiellen "Cheater" abzudecken eine billige Caesar-Chiffrierung wie ROTx? Wäre ja technisch für das Einlesen und Speichern in ein paar Minuten abgefrühstückt.

[blinder007]

wenn ich die sämtlichen spielstände und oder karten in typisierten dateien oder in "einem beliebig beklopten format" abspeichere, also über tfilestream, dürfte ich dann nicht schon ein großteil der Spieler abschrecken, weil sie nicht wissen, was sie vor sich haben? Wenn ich dann die records noch vor dem einspeichern schifriere, dürfte doch 99% aller Spieler ein Bein gestellt sein. Übrigens ist es single player, zunächst zumindestens :)

edit: was sind relationale Datenbanken?

[Der schöne Günther]

Zitat:

Zitat von blinder007 (Beitrag 1229481)

dürfte ich dann nicht schon ein großteil der Spieler abschrecken?

Ich glaube nicht nur die Spieler, auch einen Großteil der Entwickler :wink:

Spaß beiseite. Ich weiß nicht, wie sehr die Zeit drängt, aber ich persönlich würde mir - für das reine Lesen und Speichern der Daten - mindestens zwei kompatible Ansätze bauen. Einmal ein menschenlesbares Format mit dem du als Entwickler komfortabel arbeiten und prüfen kannst. Ich glaube es macht keinen Spaß in einer langen Bytewurst einen Fehler zu suchen wenn das Programm nicht das tut, was es soll.

Wenn es dann in die Veröffentlichung geht kannst du doch einfach das XML Lesen/Speichern gegen Bytewurst-Lesen/Schreiben tauschen ohne dass der Rest des Programms beinflusst wird. Das wäre jetzt mein Geschmack gewesen.

[blinder007]

muss ich dann bei der "bytewurst" :D

denn auch darauf achten, welche typen ich verwende, wegen der kompertibilität zwischen 32 und 64 bit systemen?
Ich habe mir auch überlegt: was ist, wenn ich mir ein eigenes programm zum bearbeiten und durchsuchen der "bytewürstchen" schaffe? :D
schöner Begriff übrigens :)

[DeddyH]

Man muss ja nicht die ganz große DB-Keule auspacken, für sehr einfache Strukturen tut es auch MyBase.

[edit] Wo es Probleme zwischen 32- und 64-Bit-Systemen geben soll, entzieht sich derzeit meiner Kenntnis, ein 32Bit-Programm bleibt auch unter Windows 64 32-bittig. [/edit]

[blinder007]

ich sollte echt mal meine delphi version einfügen - kann man die komponente irgendwo runterladen, benutze delphi 6 personal :(

[Der schöne Günther]

Erinnert sich noch jemand an die Zeit von Tipps, Tricks und Cheats in gedruckten Spielemagazinen die begannen mit "Besorgen Sie sich einen beliebigen Hexeditor. Auf der CD/Diskette liegt bereits XYZ bei...". :-D

Klar kannst du das tun. Aber ich glaube, die Zeit wäre effektiver eingesetzt, lieber ein komfortables und offenes Format wie XML parallel zu nutzen. Was tust du, wenn du zusätzliche Eigenschaften in der Datei unterbringen willst? Alle bisher angefallenen Dateien (z.B. Spielstände) sind jetzt nutzlos und passen nicht mehr.

Jetzt könntest du natürlich wieder ein Programm schreiben, dass bestehende Dateien untersucht, die neuen Informationen mit Standardwerten ergänzt und die neue Fassung speichert. Aber wie gesagt. Die reine, fast schon optische, Form - Das Format, wie ich am Schluss auf die Platte schreibe: Darüber würde ich mir am Schluss Gedanken machen. Zur Entwicklungszeit würde ich etwas menschenlesbares und auch von anderen leicht verständliches Format nehmen. Deine Eigenentwicklung musst du dokumentieren und das auch aktuell halten. Sonst blickt da außer dir niemand durch.

[blinder007]

ok, das klingt vernümpftig.
fassen wir also zusammen: zuerst alles in formaten wie xml abspeichern, später eigenes format schreiben, was auch noch verschlüsselt werden muss.
bedeutet, wenn ich das richtig verstanden habe, mehr arbeit aber auch übersichtlichkeit.
Probleme zwischen 32 und 64 bit systemen wird es nicht geben.
mir wird mybase empfohlen, was hält man davon? und kann man die komponente irgendwo downloaden?

[DeddyH]

Nach meiner Kenntnis kannst Du in der Personal Edition MyBase leider nicht (ohne spezielle Komponenten, die es ggf. geben mag) benutzen, da dort keine Datenbankfunktionalität und somit auch kein TClientDataset enthalten ist.