Ich stelle gerade eines unserer Projekte von klassischem C/S auf RO/DA um - ca. 100 Tabellen, ca. 750 Tausend LOC - als Fingerübung, bevor es dann an die richtig großen Projekte geht.
Es gibt mehrere Möglichkeiten bei RO/DA:
- du kannst die Menge an zurückgelieferten Datensätzen über dynamisch generierte Where-Clauses bestimmen
- du kannst die Felder, die an den Client geliefert werden sollen, durch Verwendung Dynamic-Select bestimmen
In vielen Fällen reicht es (zumindest bei mir), die Tabelle als AutoSQL im Schema zu definieren - dann sind per Definition alle Felder drin - und dann im Client die Ergebnismenge mit DynamicWhere und/oder DynamicSelect den Wünschen anzupassen - die übertragene Datenmenge wird entsprechend den Statements bereits vom Server reduziert, nicht erst im Client (wie es z.B. bei einem Filter im Client-Dataset der Fall wäre).
Wird DynamicSelect verwendet, hat AutoSQL den Vorteil, dass der RODA-Server tatsächlich nur die angegebenen Felder bei der Datenbank abfragt. Mit selbstgestricktem
SQL werden zunächt alle Felder, die im
SQL-Statement angegeben sind, bei der
DB abgefragt und erst im RODA-Server die nicht verlangten Felder ausgefiltert.
Damit hättest du im Idealfall eine Tabelle im Schema definiert und im Client ein TDAMemDataset, welches du mit verschiedenen dynamischen Statements fütterst. Ob das nun tatsächlich auch bei dir der Fall sein kann, weiß ich natürlich nicht.
Wenn dein Server in .NET geschrieben ist, kann auch DA
SQL verwendet werden. Oder LINQ.
Details und Beispiele dazu finden sich im Wiki.
Ehrlicherweise muss ich sagen: Am Anfang treibt einem RO/DA schon mal in die pure Verzweiflung, wenn man so wie ich von der reinen C/S-Schiene kommt - die Lernkurve ist gerade am Anfang sehr hoch, die Doku nicht immer optimal, stellt nur einfache Fragestellungen dar oder ist nicht mehr auf dem neuesten Stand - man muss häufig ausprobieren, was geht. Aber es lohnt sich, durchzuhalten...
