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.