RemObjects Data Abstract, wozu Schema?

[Kostas]

Hallo Zusammen,

ich versuche RemObjects und Data Abstract zu verstehen.
Wenn ich das richtig verstanden habe, Wird durch das Schema in Data Abstract
die Datenbankstruktur "Nachgebildet" Jedes Element aus dem Schema muss mit
einem BusinessProcessor auf der Form verbunden werden. Eine MemDataTable kann
dann mit einem BusinessProcessor als Datenresource verbunden werden.

Das verstehe ich wenn unterschiedliche Datenbanken mit der gleichen Struktur
angesprochen werden sollen(Field Mapping).
Ich frage mich, ob das Schema auch notwendig ist wenn ausschließlich eine
Datenbank "Firebird" verwendet werden soll?

Was ich mir eigentlich vorstelle ist, im AppServer sollen anhand von SQLs die
auch Joinings enthalten können, Datasets produziert werden und die Clients sollen
die Datasets konsumieren können.

Geht dieser Weg so wie ich mir das vorstelle, oder muss ich zwingend mit Schema
und BusinessProcessor arbeiten?

Gruß Kostas

[Phoenix]

Das Schema ermöglicht es Dir, die den Clients zur Verfügung gestellten Daten anders zu Modellieren als sie physikalisch in der Datenbank liegen. Das ganze dient dazu, ein Business-Model mit Logik zu erstellen, ohne sich dabei auf die echte Tabellenstruktur festzufahren.

Du wirst merken, dass Du vorne auf einmal viel flexibler wirst, wenn Du die Datenbank nicht einfach so 1:1 an den Client durchreichst, sondern die technischen Details der Normalisierung hinter dem Schema versteckst. Deswegen ist das schon der korrekte Ansatz mit dem Schema zu arbeiten.

[Kostas]

Danke für die Antwort Sebastian,

ich spiele jetzt mal gedanklich eines meiner Projekte durch, welches relativ groß ist.
Es enthält 374 Tabellen. Die Adresstabelle hat 112 Felder. In der gesamten Anwendung
gibt es keine Stelle die alle Felder aus der Adresstabelle verwaltet. Wenn ich ein
Adressetikett drucke, hole ich mir nur die Adresse. Bei einem Auftrag hole ich mir
zusätzlich die Bankdaten für die Lastschrift. u.s.w. Alleine für die Adressen habe
ich mehrere Duzend TIB_Query(IBO Komponenten)die per Select mit Joins nur eine Untermenge
der Adressenfelder anfordern. Hier passiert auch punktuell die Datenprüfung.
(Die Prüfung punktuell ein klarer Nachteil gegenüber Multi-Tier)

Aber wie wird dieses Scenario konkret mit Data Abstract Schema abgebildet?
Habe ich ein Mapping auf die Tabelle Adressen mit 112 Felder und genau ein
BusinessProcessor, oder sind das mehrere Schemata-Table-Items mit jeweils einen
BusinessProcessor?

Gruß Kostas

[kretabiker]

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...

[Kostas]

Danke Leidensgenosse.

aktuell mache ich auch reine C/S Anwendungen mit IBO und Firebird.
RO-DA scheint ein mächtiges Werkzeug zu sein. Durch die intelligente Anpassung der SQLs die zum Server
gesendet werden, könnte vermutlich der Overhead bezüglich Performance keine Rolle mehr spielen.
Was bleibt ist der erhebliche Mehraufwand den eine Multi-Tier Umgebung mitbringt. Man muss schon
genauer abschätzen ob Multi-Tier für das konkrete Projekt Sinn macht. Doch leider ist es nicht immer
über die Glaskugel zu erfragen wie das Projekt sich in 10 Jahren entwickeln wird. Die Anforderungen des
Kunden wachsen oder auch nicht.

IBO soll ersetzt werden durch AnyDAC die ich schon gekauft habe.
Jetzt habe ich gesehen, wenn ich mich für RO-DA entscheide, dass es auch ohne AnyDAC gehen könnte.
Was RO-DA nicht haben wird, sind die Zusatzkomponenten z.B.: für Backup u.s.w.
Irgendwie habe ich bei den Beispielen den DataServer gesehen dass AnyDac direkt verwendet oder
unterstützt wird. So ganz habe ich das noch nicht herausgefunden wie es zusammenhängt.
Gruß Kostas

[kretabiker]

Was DB-Treiber angeht: RO/DA unterstützt von Haus aus eine Reihe Treiber, die ggfs. manuell installiert werden müssen - siehe http://wiki.remobjects.com/wiki/Drivers. So auch in meinem Fall: Treiber ist IBDAC, wird von RO/DA unterstützt, manuelle Installation erforderlich - es ist dafür eine IBDAC-Lizenz erforderlich, damit die Installation möglich ist. Ähnlich sollte es auch bei AnyDac laufen.