Daten von versch. Quellen zusammenfassen mit Dataset?

[FatPap]

Hallo

Folgende Situation:

Ich arbeite mit Rad Studio XE2.

Mehrere client Applikation verbinden sich mit einem Server. Der Server verwaltet verschiedene Anlagen (Maschinen). Diese Maschinen loggen die verschiedensten Ereignisse und Fehler und speichern diese in einer Textdatei oder mysql bzw. sqlite Datenbank oder in irgendeiner anderen Form auf dem Server.

Die clients senden Anfragen an den Server. So eine Anfrage könnte in etwa so aussehen:

->Alle Fehler und Warnungen von Anlagentyp:Heber seit 3.Juli sortiert nach Zeit aufsteigend

Die Struktur sieht in etwa so aus:
Anlagentyp | MacAdresse | Typ | Timestamp | Text | Bediener

Der Server greift nun laut Anfrage auf die Daten zu und bildet daraus eine gemeinsame Datenmenge. Die Daten aus den verschiedenen Quellen auszulesen stellt für mich kein Problem dar.

Aber bevor ich die Daten an den Client senden kann (TCP/IP) muss ich ich sie in irgendeiner Form im Haupspeicher des Servers haben.
Als array of record?
Ich hab noch nie mit Datasets zu tun gehabt aber ich denke es wäre wohl das richtige in meinem Fall? (gerade wenn ich ans sortieren denke)

Hat jemand Anregungen dazu?

[himitsu]

Wie werden die Daten denn übertragen?

Wenn die Daten als Record rein kommen und als Record wieder versendet werden, dann könnte man sich schon überlegen, ob es unbedingt sinnvoll wäre, alles nochmal in ein DataSet umzukopieren.
Obwohl das Sortieren doch auch notfalls er Client machen könnte, wobei man die Daten nicht jedesmal neu holen muß, wenn der Benutzer die Anzeige danach im Grid nochmal umsortieren oder filtern möchte.


DataSets ohne Datenbank, wären praktsich Memory-DataSets, wie z.B. das TClientDataSet vom Delphi.
Da kannst du z.B. im OI die Spalten definieren und das DataSet dann ganz normal verwenden.

Da einige Daten aus Datenbanken kommen, wäre der Weg mit dem DataSet aber doch nicht verkehrt.
So könnte man einmal eine normale Query-Komponenten verwenden, für die Daten aus den Datenbanken und ein Memory-Dataset, welche mit den Daten aus anderen Quellen stammen.

Beim Sortieren der MemoryDatasetz, kannst du Diese über TDataSet.MoveBy sortieren, aber ob das normale Query-Komponenten auch unterstützen, weiß ich nicht, aber da kann man ja ein ORDER BY verwenden, um das sortiert zu lasen.


Wobei man aber ein Array oder eine TList oder TList<> auch problemlos sortieren kann.

[Dejan Vu]

Mit DataSnap geht das supereinfach.

Wenn Du die Daten dann noch in einer SQL-fähigen Datenbank ablegst (Firebird, SQL-Server etc.) Dann kannst Du eine beliebige SQL-Query an den Server schicken und bekommst immer die richtigen Daten...

Es gibt bestimmt ein paar Tutorials zu dem Thema. Eigentlich ist das nur: Komponenten auf Datenmodule packen, verknüpfen, fertig. Programmieren muss man da nicht mehr.

[himitsu]

Zitat von Dejan Vu:

Mit DataSnap geht das supereinfach.

Professional ... da ist das nicht mit dabei

Aber ja, auf der einen Seite ein DataSet befüllen und um die Übertragung kümmert sich das DataSnap.
Am Ende ist das fast wie ein lokaler Prozeduraufruf, wobei DataSnap den Aufruf zum Server schickt und die Antwort (hier das DataSet) zurück holt.
z.B. function TMyDataSnapModul.HoleMeldungen(Anlagentyp: string; MeldungenSeit: TDataTime; Aufsteigend: Boolean=True): TDataSet;

[FatPap]

Danke für die ausführlichen Antworten

Zitat:

Professional ... da ist das nicht mit dabei

Was ist damit gemeint?
edit: Du meintest wahrscheinlich die XE2 Version. Ja ich verwende Professional.

Ich hatte gerade ein Gespräch mit dem Chef.

Wir stellten fest dass es ungünstig ist immer von verschiedenen Quellen abzufragen. Deshalb wird auf dem Server auch eine lokale Datenbank (sqlite) zur Anwendung kommen in der sämtliche Daten der verschiedenen Anlagen eingetragen werden.
Für den Umgang mit sqlite habe ich einen Delphi Wrapper -> https://github.com/plashenkov/SQLite3-Delphi-FPC

Am server werden die Daten dann so abgefragt:

Delphi-Quellcode:

var Statement : TSQLite3Statement;
begin
  Statement := Database.Prepare('SELECT * from table where bla bla bla');
  while Statement.Step = SQLITE_ROW do
  begin
    RecordOderSonstwas.Feld0 := Statement.ColumnText(0);
    RecordOderSonstwas.Feld1 := Statement.ColumnText(1);  
    usw...
  end;
end;

Zum Übertragen verwende ich die INDY_10 Komponente TIdTCPServer und TIdTCPClient.
Also stellt sich für mich jetzt die Frage was nehmen für "RecordOderSonstwas" (bzw. warum die Daten nicht einfach im Statement lassen und direkt übertragen) und in welcher Form übertragen?

Wie ich einen Record mit dem TCPServer übertrage hab ich schon herausgefunden:

Delphi-Quellcode:

procedure TFrmStart.TCP_SERVERExecute(AContext: TIdContext);
var Buf : TidBytes;
begin
  Buf := RawToBytes(einRecord, Sizeof(einRecord));                       
  AContext.Connection.IOHandler.Write(Buf);
end;

Ich und google werden sich jetzt mal mit Datasnap und TClientDataSet auseinandersetzen.

[taveuni]

Zitat von FatPap:

Ich und google werden sich jetzt mal mit Datasnap und TClientDataSet auseinandersetzen.

Dann zieh auch mal noch RemObjects in betracht.
Insbesondere wenn Du Delphi unabhängig(er) entwickeln willst.

[mkinzler]

Oder
mORMot
RemoteDB

[Sir Rufo]

Zitat von FatPap:

Ich hatte gerade ein Gespräch mit dem Chef.

Wir stellten fest dass es ungünstig ist immer von verschiedenen Quellen abzufragen. Deshalb wird auf dem Server auch eine lokale Datenbank (sqlite) zur Anwendung kommen in der sämtliche Daten der verschiedenen Anlagen eingetragen werden.

Der Kern-Anwendung sollte es völlig egal sein, wo die Daten genau herkommen. Die muss nur wissen, wie sie an die Daten kommt. Das erledigt man über die Definition von Repositories. Das jeweilige Repository weiß, wie man an die Daten kommt und die Anwendung fragt einfach das Repository. Schon wird es (aus Sicht der Anwendung) egal, wo die Daten liegen und wie die konkrete Abfrage zu bewerkstelligen ist.

Delphi-Quellcode:

// Generisches Repository
type
  IRepository<T,TID> = interface
    function Find( AID : TID ) : T;
    function FindAll : TList<T>;
  end;

  IPersonRepository = interface( IRepository<TPerson,integer> )
    function FindByName( const AName : string ) : TList<TPerson>;
  end;

Eine Konzentration von Daten in einer Datenbank, nur aufgrund von Befindlichkeiten des Programmierers, ist mE völlig unsinnig und kann uU mehr Probleme schaffen.

Zitat von FatPap:

Zum Übertragen verwende ich die INDY_10 Komponente TIdTCPServer und TIdTCPClient.
Also stellt sich für mich jetzt die Frage was nehmen für "RecordOderSonstwas" (bzw. warum die Daten nicht einfach im Statement lassen und direkt übertragen) und in welcher Form übertragen?

Wie ich einen Record mit dem TCPServer übertrage hab ich schon herausgefunden:

Delphi-Quellcode:

procedure TFrmStart.TCP_SERVERExecute(AContext: TIdContext);
var Buf : TidBytes;
begin
  Buf := RawToBytes(einRecord, Sizeof(einRecord));                       
  AContext.Connection.IOHandler.Write(Buf);
end;

Solange du in dem Record keine string Typen verwendest wird das auch so funktionieren - sonst aber nicht.
Bei einem String befindet sich im Record lediglich eine Referenz auf den String und nicht der String selber.

Such mal nach Serialisierung (z.B. nach JSON oder XML) und übergib das an den Client. Der kann sich daraus dann wieder eine Instanz/Record zusammenbauen.

[himitsu]

Zitat:

Was ist damit gemeint?
edit: Du meintest wahrscheinlich die XE2 Version. Ja ich verwende Professional.

Jupp, und DataSnap gibt es erst ab der Enterprise. -> Feature Matrix

http://en.wikipedia.org/wiki/DataSnap
http://docwiki.embarcadero.com/RADSt...gen_entwickeln
http://docwiki.embarcadero.com/RADSt...nd_Architektur

[FatPap]

mORMot klingt interessant danke.

Zitat:

Eine Konzentration von Daten in einer Datenbank, nur aufgrund von Befindlichkeiten des Programmierers, ist mE völlig unsinnig und kann uU mehr Probleme schaffen.

Daten müssen auch verfügbar sein wenn eine Anlage mal gerade nicht läuft.

Zitat:

Solange du in dem Record keine string Typen verwendest wird das auch so funktionieren - sonst aber nicht.

Ja, musste die strings bisher so definieren string[255] Danke für den Tipp.