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.