Einzelnen Beitrag anzeigen

kretabiker

Registriert seit: 10. Mär 2005
Ort: Bargteheide
181 Beiträge
 
Delphi 10.1 Berlin Professional
 
#7

AW: RemObjects Data Abstract, wozu Schema?

  Alt 20. Nov 2012, 10:44
Und was die Entscheidung für RO/DA angeht: Auch hier bei uns war die Entscheidungsfindung ein mühsamer, durchaus langwieriger Prozess, während dessen ich mich mit kleinen und kleinsten Projekten auf maximal Toolniveau mit der Materie RO/DA auseinandergesetzt habe - ich glaube, die erste RO/DA-Lizenz habe ich Sommer 2008 geordert, und ERST DIESES JAHR geht es ernsthaft an die Umstellung. Letztendlich ausschlaggebend waren die zusätzlichen Möglichkeiten, die ich dadurch erlange: Zum einen habe ich einen performanten, verschlüsselten, komprimierten Datenübertragungsweg, den ich von Delphi-, .Net- oder gar XCode-Clients nutzen kann. Zusätzlich besteht aber auch die Möglichkeit, mit skriptbasierten Sprachen wie z.B. PHP via Webservice/SOAP die gleiche Schnittstelle anzusprechen und damit browserbasierte Clients zu bedienen (ob es Sinn macht, tatsächlich die gleiche Schnittstelle zu nehmen oder parallel eine für SOAP aufzubauen, sei dahingestellt - wichtig ist: Es ist der gleiche Server!) - Stichwort Windows 8 und die neue WinRT-Welt oder mobile Clients.

Wohin die Reise letztendlich geht, kann ich nicht sagen. Aber die Möglichkeiten, die sich mir und meinem Delphi-Wissen mit RO/DA bieten, sind vielversprechend. Jetzt baue ich den Server mit Delphi. Sollte eines Tages die Entscheidung gefällt werden (müssen), nicht mehr auf Delphi zu setzen, kann ich in aller Ruhe den Server z.B. auf .NET umstellen und mir nen .NET-Spezi schnappen, der den/die Clients neu schreibt - oder nen HTML(5)-Spezi, der was für Browser macht. Oder beides. Oder alle drei Möglichkeiten parallel - was eben gerade benötigt wird: Die Businesslogik und die Datenbankhandlings liegen immer im RO/DA-Server, was mir unglaublich viel Flexibilität gibt bei den Clients - so richtig schlau müssen die im Gegensatz zu C/S-Clients ja nicht mehr sein...

Mal davon abgesehen: Die Freiheit beim Einsatz des verwendeten Datenbanksystems. Wir nutzen Firebird mit IBDAC und sind äußerst zufrieden. Was ist, wenn aber die erzeugten Datenmengen - es geht hier bei uns um touristische Daten, z.B. Hotelpreise, wo mal locker pro Hotel ein paar hunderttausend Datensätze auf einen Schlag in der DB erzeugt werden müssen - die Möglichkeiten von FB sprengen und den Einsatz von von mir aus Oracle verlangen? Den Clients bleibt es egal, durchs Schema sind sie von der Anpassung im Backend isoliert. Und das Schema anzupassen ist ja nun wirklich ein Kinderspiel im Vergleich zu den Änderungen bei einer reinen C/S-Anwendung - das habe ich schon zweimal durchexerziert (BDE/Paradox->IBX, IBX->IBDAC) und habe davon eigentlich die Nase gestrichen voll.
Udo Treichel
  Mit Zitat antworten Zitat