Statistik/Nutzerdaten (Backend) in wechem Format speichern?

[CocoPops]

Liebes DelphiPraxis-Team!

Ich arbeite momentan an einem größerem Projekt und möchte das Projekt gerne durch eine Statistik erweitern.
Jedoch bin ich mir nicht sicher, in welchem Format ich die gewonnenen Daten abspeichern soll.

Es handelt sich hierbei um Daten wie Betriebssystem, Architekture und vieles mehr.

Ich dachte schon an das JSON-Format. Aber das ist zuviel Arbeit für ein so kleines Feature im Programm.
Andererseits habe ich an ein CSV-ähnliches Format gedacht (ohne Anführungszeichen): "OS:Windows 7 Home Premium;Architecture:.x64;SP:SP1;" und so weiter.
Und letztendlich dachte ich an ein Ini oder XML-ähnliches Format.

Momentan tendire ich stark zum CSV-ähnlichem Format, weil ich das leicht in PHP auswerten kann.


Was meint ihr?

[Perlsau]

Du könntest z.B. ein TClientDataSet verwenden, damit könntest du dann eine TDBChart-Komponente füttern.

[CocoPops]

Hallo Perlsau, danke für diesen Beitrag und danke für die Idee.
Aber meine Daten sind lediglich Nutzerdaten, welche meine Software, nach vorrangegangener Zustimmung des Nutzers, nach Hause sendet.
Es sind also für den Nutzer nicht sichtbare Daten.

Mein Problem besteht darin dass ich nicht weiß, in welchem Format ich die Daten speichern soll.

[Perlsau]

Wenn ich dich recht verstehe, möchtest du wissen, welche Möglichkeiten der Datenspeicherung überhaupt existieren. Dabei irritiert mich ein wenig die Aussage, daß die Daten für den Nutzer nicht sichtbar sein sollen. Meinst du damit, daß die Daten nicht auf Platte gespeichert werden sollen?

Am besten verschaffst du dir einfach mal einen groben Überblick, indem du dir diese Tutorials zur Datenspeicherung zu Gemüte führst. Des weiteren wird ebenfalls im Delphitreff die Speicherung via TClientDataSet ausführlich beschrieben.

[himitsu]

CSV mit nur einer Zeile? (OK, ist natürlich möglich)
Man könnte auch pro Zeile einen Wert machen.

INI würde ich eher nicht mehr verwenden.
Nja, das StringList-Format mit Name=Wert pro Zeile wäre zumindestens noch gut nutzbar.

Insgesamt ist eine namentliche Zuordnung eh besser, falls sich mal was am Format ändert, bzw. an den enthaltenen Daten.


Für XML hat PHP schon länger eine mehrere Unterstützungen drin und JSON wird es vermutlich auch irgendwo geben.

[CocoPops]

Hallo Perlsau, exakt. Die Daten sind für den Nutzer nicht sichtbar.

Meine Software sammelt die verschiedenen Daten nach Zustimmung des Nutzers und sendet diese dann nach Hause. Dort, auf dem Server, werden die Daten dann gespeichert und sind für mich später in einem Front-End einsehbar. Aber um effizient zu bleiben, möchte ich ein ebenso effizientes Format wählen.

Ein CSV-ähnliches Format ist sehr einfach zu realisieren (Zeichen-getrennte Strings) und ich brauche keine Bibliotheken und so weiter. Aber macht das Sinn?
Denn ich habe ein wenig Sorge, dass eine einzige Zeile mit einer Länge von bis zu 500 zeichen zu lang sein könnte.

PHP unterstüzt JSON, das ist korrekt. Aber in Delphi ist es ein regelrechter Murks das Format umzusetzen, ohne mindestens eine Bibiothek einzubinden.

[Perlsau]

Den Sinn legst du doch selber fest! Wenn du das leicht auswerten kannst, dann mach es eben via CSV. Allerdings ist eine CSV-Datei auf der Platte sehr wohl vom Anwender darstellbar. Aber was soll's? Damit machst du deine Anwendung transparent und gestattest dem User die Kontrolle darüber, was an den Homeserver gesendet wird.

Wenn du ein ClientDataSet verwendest, kanns du das auch verschlüsselt abspeichern. Gesendet wird ja sowieso innerhalb derselben Anwendung, dann liest du die ClientDataSet-Datei wieder in ClientDataSet ein und versendest die Daten entschlüsselt.

Ansonsten hab ich keine Ahnung, welche Antwort du eigentlich erwartest.

[Sir Rufo]

Das Speicher-Format sollte aus Sicht der Anwendung völlig egal sein.
Das ist Aufgabe des Persistent-Layers. Der stellt der Anwendung die Objekte mundgerecht zur Verfügung bzw. kümmert sich um das Speichern.

Delphi-Quellcode:

type
  TData = record
  private
    FId : string;
    FValue : string;
  public
    constructor Create( const Id, Value : string );
    property Id : string read Fid;
    property Value : string read FValue;
  end;

  IDataRepository = interface
    function Find( const Id : string ) : TData;
    function FindAll : TArray<TData>;
    procedure Save( AData : TData );
  end;

Somit stellt sich nicht die Frage, was kann ich wo ganz toll ver-/bearbeiten, sondern mit welchem Format habe ich mit dem Persistent-Layer den geringsten Aufwand. ;)

[CocoPops]

Zitat:

Zitat von Perlsau (Beitrag 1253822)

Den Sinn legst du doch selber fest! Wenn du das leicht auswerten kannst, dann mach es eben via CSV. Allerdings ist eine CSV-Datei auf der Platte sehr wohl vom Anwender darstellbar. Aber was soll's? Damit machst du deine Anwendung transparent und gestattest dem User die Kontrolle darüber, was an den Homeserver gesendet wird.

Ich hab keine Ahnung, welche Antwort du eigentlich erwartest.

Dass dem Anwender sichtbar gemacht werden soll, was denn gesendet wird, klingt gut. Das werde ich noch implementieren denke ich.

Ich erwarte nichts. Ich erhoffe mir nur konstruktive Kritik gegenüber den von mir oben genannten Datensicherungsformaten =)
Das Ini-Format scheidet nach himitsu demnach schon einmal aus, da zu alt.

Zitat:

Somit stellt sich nicht die Frage, was kann ich wo ganz toll ver-/bearbeiten, sondern mit welchem Format habe ich mit dem Persistent-Layer den geringsten Aufwand.

Das stimmt auch mal wieder.

[CocoPops]

Ich quote mich mal wenn ich darf:

Zitat:

Ein CSV-ähnliches Format ist sehr einfach zu realisieren (Zeichen-getrennte Strings) und ich brauche keine Bibliotheken und so weiter. Aber macht das Sinn?
Denn ich habe ein wenig Sorge, dass eine einzige Zeile mit einer Länge von bis zu 500 zeichen zu lang sein könnte.

[DeddyH]

Nach meiner Kenntnis dürfen POST-Daten technisch unbegrenzt lang sein, allerdings gibt es in PHP eine Variable post_max_size, die die maximale Länge festsetzt. Laut php.net liegt der Vorgabewert bei 8M, das sollte eine Weile genügen.

[Jumpy]

Moment mal, ich komm nicht mehr mit.
Geht es denn jetzt darum in welcher Form die Daten nach Hause geschickt werden? Oder darum wie die zuhause angekommenen Daten dort (zuhause) gespeichert werden? Dann wäre doch "in der Datenbank" auch eine mögliche Antwort.

[CocoPops]

Es geht darum, wie die Daten zu Hause gespeichert werden sollen.

Eine Datenbank ist eine sehr gute Alternative, aber ich speichere meist immer alles in Dateien ab statt in einer Datenbank. Denn ich habe meine Daten gerne zentral an einer Stelle und nicht an zick verschiedenen.

[DeddyH]

Aber was kann zentraler sein als eine Datenbank?

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1253857)

Aber was kann zentraler sein als eine Datenbank?

Eine zentralisierte Zentral-Datenbank in der Zentrale vielleicht? :stupid:

[CocoPops]

Ich mag Datenbanken einfach nicht ;) Ende

[sx2008]

Das kann doch nicht so schwer sein ein passendes Format zu finden.
1. überlege ob das Datenformat hierarchisch (JSON, XML) sein muss oder ob es auch flach (CSV, INI-Files) sein darf.
2. da du das Datenformat in zwei versch. Programmiersprachen verwendest, sollte es möglichst bekannt sein um vorhandene Bibliotheken benützen zu können
3. ebenso sollte das Datenformat von Menschen lesbar sein (binäre Datenformate sind zwar platzsparender aber auch schwerer zu testen)

Da du CSV und Ini-Files schon ausgeschlosssen hast bleibt nur noch JSON und XML von den Mainstream Formaten übrig.
YAML kann man ausschliesen weil zu komplex und zu wenig Delphi Support.

[CocoPops]

Letztendlich habe ich ein CSV-ähnliches Format genommen. Es scheint mit etwa 800 Zeichen pro Zeile das platzsparendste zu sein, da keine unnötigen Dinge gespeichert werden. Hier ein Beispiel:

Code:

Ident:Value;IdentA:ValueA;IdentB:ValueB

[himitsu]

Delphi-Quellcode:

SL := TStringList.Create;
SL.NameValueSeparator := ':';
SL.Delimiter := ';';
SL.Values['Ident'] := 'Value';
SL.Values['IdentA'] := 'ValueA';
SL.Values['IdentB'] := 'ValueB';
ShowMessage(SL.DelimitedText);

Delphi-Quellcode:

SL := TStringList.Create;
SL.LineBreak := #10;
SL.Values['Ident'] := 'Value';
SL.Values['IdentA'] := 'ValueA';
SL.Values['IdentB'] := 'ValueB';
ShowMessage(SL.Text);

:angel:

[CocoPops]

Ah, ich glaube ich wurde falsch verstanden.
Die Umsetzung ist schon erfolgt ;) ;)

[himitsu]

Neee, keine Sorge :lol:

Das Erste ist "deine" Lösung
und das Zweite wurde auch schonmal genannt.