Switch Oracle auf MS SQL-Server

[toschmaster]

Hallo *

ich hab hier eine Deplhi-Anwendung (win32) die bisher mit Oracle arbeitet. Aus Kostengründen soll es nun aber ein MS SQL-Server werden.

Ich selbst hab so einen Switch noch nicht gemacht (zumindest mit Delphi). Hat da jemand schon Erfahrungen gemacht und kann mir erst mal sagen wie aufwendig so eine Geschichte ist (Stunden, Tage, Wochen)? Soll das gerade mal Abschätzen ohne wirklich Erfahrung damit zu haben

[hoika]

Hallo,

der Aufwand richtet sich nach dem Code
und deiner Erfahrung mit beiden Datenbanken.

- wie viel DBCode ist es
- alles schön gekapselt
z.B. keine TTable/TQuery auf Forms
- stored procedures verwendet ?

Zu den Kosten:
Warum nicht gleich PostgreSQL oder Firebird ?


Heiko

[Bernhard Geyer]

Am besten gleich den Switch nutzen und beide DB's unterstützen. Hierfür bietet sich die realisieren nach dem Bridge-Pattern an.

[nahpets]

Hallo,

habe ich mal gemacht, ist schon ein paar Jahre her.

Das Programm lief seinerzeit mit der BDE, so das im Programm selbst keine Änderungen erforderlich waren. Neuen Datenbankalias einrichten und loslegen.

Besonderheit bei dem Programm war:

Alle SQL-Statements lagen in einer Datenbanktabelle und wurden bei Bedarf dort gelesen, dann die Parameter befüllt und auf die Datenbank "losgelassen".

Es waren also nur die in der Datenbanktabelle liegenden SQL-Statements (bei Bedarf) an die unterschiedliche Syntax des SQL-Servers anzupassen. Hat mich seinerzeit incl. Testen etwas über 2 Tage gekostet (ca. 250 SQL-Statements, davon war weniger als die Hälfte anzupassen etwa 100).

Wenn Du allerdings im Programm Änderungen vornehmen musst, dort die Zugriffskomponenten austauschen musst, kann das deutlich aufwändiger werden. Um hier aber auch nur ansatzweise helfen zu können, müssen mehr Infos her:

Wieviele Datenbankkomponenten, wieviele Tabellen, Querys... werden genutzt?
Wieviele SQL's kommen zum Einsatz, wie komplex sind sie? Einfache select spalte... from tabelle sind quasi belanglos, das sollte 1 zu 1 übernehmbar sein. Bei SQL-Funtionen in den Statements, Unions, geschachtelten SQL's

SQL-Code:

select * from (
  select * from tabelle1 t1, tabelle2 t2 where t1.id = t2.id
)
order by 1,2,3

wird es aufwändiger, da hier die Syntax beim SQL-Server anders ist, der kennt keine Unnamed-Views. Da muss dann

SQL-Code:

select * from (
  select * from tabelle1 t1, tabelle2 t2 where t1.id = t2.id
) irgendeinname
order by 1,2,3

draus werden.
Joins kannst Du unter Oracle mit (+) machen, das kennt der SQL-Server nicht, an solche Sachen musst Du dann auch ran.

Um eine treffsichere Schätzung machen zu können, musst Du sehr gut wissen, wie es jetzt aussieht und wie es in Zukunft aussehen muss.

Wir haben hier die Faustregel: So gut abschätzen wie wir mit dem vorhandenen Wissen können. Ist die Unsicherheit nicht alszu groß, das geschätzte Ergebnis in Stunden, Tage * 2, ist die Unsicherheit groß, dann * 3, ist die Ungewissenheit fast schon sicher * 4 oder auch Auftrag wegen Unkalkulierbarkeit ablehnen.

Zu Alternativen Postgres: Hier vermute ich, dass der Änderungsaufwand auf SQL-Seite niedriger ist, als bei SQL-Server, die SQL-Dialekte von Oracle und Postgres scheinen mir größere Ähnlichkeit zu haben, als Oracle und SQL-Server. Und wenn schon Kostenargument, warum dann nicht Postgres auf Linux: Keine Datenbankkosten, keine Betriebssystemkosten. Den Admin braucht man in beiden Fällen.

[hoika]

Hallo

OT: aber, ca. 250 SQL-Statements ???

Nur 250 ?
Was war das denn für ein Program ?

Der Ansatz ist aber nicht schlecht.
Hast du die Statements alle beim Start geladen
oder bei Bedarf ?

Firebird (3) wird übrigens viele Oracle-Sachen können,
kommt aus Fyracle.


Heiko

[toschmaster]

Wow das ging aber schnell!

Also DB-Zeilen Code geht deutlich in 4-stelligen Bereich (weit über 250 Statements ). Aber den zu portieren ist zum Glück nicht meine Aufgabe. Der DB-Source ist in Packages gepackt die eigentlich nur Prozeduren enthalten. Auf das Package wird über Direct Oracle Access zugegriffen. Zugriffe auf die DB finden ausschlisslich und komplett über dieses Package statt. Somit sollten Anpassungen am Delphi-Source gegen Null tendieren.

Dieses Vorgehen soll auch weiterhin beibehalten werden.

Warum MS SQL-Server und nicht PostgreSQL oder ...? Nur Oracle und MS-SQL-Server werden von den Sys-Admins unterstützt. Unternehmenspolitik!

Die Unterstützung für beide DBs wird es natürlich geben. In welcher Form und wie komfortabel ist aber noch nicht raus.

Darum erstmal nur die Abschätzung was das Minimum an Arbeit betrifft:
- Switch auf MSSQL
- Anbindung der Prozeduren im SQL-Server

[nahpets]

Hallo

@Hoika,

das war eine Verwaltung für sagen wir mal Umsatzbeteiligungen (war schon etwas kompilizierter gibt aber die Aufgabe ganz gut wieder).

Die SQL's habe ich bei Bedarf geladen, im Programm gab's eine Query zum Laden der SQL's (das einzige "festverdrahtete" SQL im Programm).
Eine zweite Query war für alle Abfragen zuständig und eine dritte für die Datenmanipulation. Das lag alles auf einem Datenmodul. So konnte ich die Übernahme in die Stringgrids bzw. die Ausgabe als CSV, XML und für die Reports von "überall" her machen. Einfach sagen: Bitte gib mir das Ergebnis von SQL 47 (oder so), Daten abholen und anzeigen/ausgeben oder halt ein SQL anfordern, die Query wurde dann mit dem SQL versehen, vom Programm die Parameter befüllt und dann dem Datenmodul sagen. Schieb das mal in die Datenbank. Die Fehlerbehandlung lief im Datenmodul ab, so dass der Aufwand bei Progammänderungen (in Bezug auf die Datenbank) sehr gering war. SQL's in Datenbanktabelle ändern, im Programm ggfls. die Übergabe der Parameter anpassen, wenn halt was dazu kam oder wegfiel.

Das Programm ist ohne Änderungen am Programm selbst von dBase über Interbase nach Oracle und dann zum SQL-Server gewandert. Die übrigen Datenbanken könnte man genausogut "abfackeln". Da die Software mandantenfähig war, konnten die einzelnen Mandanten auch unterschiedliche Datenbanken nutzen, sie bekamen halt "ihre Datenbank" mit der entsprechend gefüllten Tabelle für SQL-Statements und konnten loslegen. Da hies aber auch, ein Benutzer des Programmes arbeitete mit "seinem" Client bei den unterschiedlichen Mandanten gegen unterschiedliche Datenbanken, er bekam nicht mit, welcher Datenbankserver da mit ihm zusammenarbeitete oder ob bei dBase die Tabellen lokal lagen. Gut, war ein kleines Programm mit wenigen Nutzern, so das die Mandantenfähigkeit und die Fähigkeit, gegen verschiedenen Datenbanken zu arbeiten, nie wirklich ausgereizt wurde.

@toschmaster

D. h.: Die Hauptarbeit liegt bei den Datenbänkern. Kann Deine bisherige Datenbankschnittstelle mit dem SQL-Server umgehen oder musst Du Komponenten austauschen. Wie sind die Unterschiede zwischen den Packageaufrufen von Oracle und SQL-Server? Da dürfte ja dann ggfls. der für Dich größte Aufwand liegen (oder im Idealfall gar kein Aufwand).

[toschmaster]

@nahpets
ja die meiste Arbeit liegt bei den DB-Jungs. Die Komponenten für die DB-Schnittstelle müssen ausgetauscht werden (Aufwand: keine Ahnung). Mit den Packageaufrufen im MS SQL-Server geht es mir leider ähnlich. Aber soviel ich weis, gibt es beim SQL-Server so etwas wie Packages nicht sondern vielmehr einzelne Prozeduren (lass mich da aber sehr gerne eines besseren belehren).
Deshalb fällt mir auch eine Aufwandsschätzung (nur für den Schnittstellen-Switch und die Prozedur-Aufrufe) nun so schwer!

[nahpets]

Hallo,

leider habe ich vom Packageaufruf bzw. Storedprocedureaufruf aus Delphi heraus keine Ahnung, so dass ich da so aus dem Bauch heraus garnichts zu sagen kann, da stehe ich absolut auf dem Schlauch.

Wie sehen die jetzigen Datenbankkomponenten aus, wie viele sind es?
Wie sehen die "neuen" Datenbankkomponenten aus, werden es genauso viele sein: Sprich ein 1:1 Ersatz oder muß aus einem "Oracleaufruf" eine mehr oder weniger große Anzahl von "SQL-Serveraufrufen" werden? Um das abzuschätzen, muss dann die Frage nach dem Umfang der Änderungen auf Datenbankseite beantwortet sein.

Der Umstieg von z. B. TQuery auf TAdoQuery ist kalkulierbar, hier sind im Wesentlichen die Parameterübergaben anzupassen:

Delphi-Quellcode:

Query1.ParamByName('Spalte47').AsString := 'irgendwas';;
ADOQuery1.Parameters.ParamByName('Spalte47').AsString := 'irgendwas';

Das sollte kalkulierbar und auch automatisierbar sein, wie sieht das bein den von Dir bisher verwandten und in Zukunft zu verwendenden Komponenten aus?

Wenn ich mal so an meine Oracle-Packages zurückdenke und deren Kompexität und Leistungsfähigkeit, so wüsste ich nicht, wie ich das "mal eben" auf SQL-Server umstellen kann. Hier dürfte ein deutlich höherer Aufwand liegen, als im Delphiprogramm. Nur: Die Art der Realisierung dieser Datenbankänderungen hat ja einen nicht unerheblichen Einfluß auf die Änderungen im Delphiprogramm.
Da jetzt ohne Detailkenntnisse eine Aufwandschätzungshilfe zu liefern, halte ich für verantwortungslos. Selbst mit Detailkenntnissen würde mir eine derartige Schätzung noch einiges an Bauchschmerzen bereiten.

Hat schonmal jemand hinterfragt, inwieweit der hier zu betreibende Aufwand durch die Ersparnis beim Server noch lohnend erscheint, wenn doch beide Datenbanken weiterhin unterstützt werden sollen?

Nicht zuletzt: Wieviel Aufwand wäre es, dass Delphiprogramm neu zuschreiben, als Programm, dass gegen einen SQL-Server läuft? Ist dieser Aufwand eventuell geringer (und weniger fehleranfällig) als ein Umbau?
In welchem "Zustand" ist das Programm? Schon (wir sagen da immer) kaputtgepflegt oder in einem Neuzustand?
Können die zu ändernden Stellen vorab schon eindeutig identifiziert werden oder muss man sich da eher so durchwuseln, in der Hoffnung, alles zu finden?

[toschmaster]

Also was den Kosten/Nutzen-Wert betrifft sind wir Entwickler uns einig, dass dies in keinem Verhältnis steht. Deshalb ist auch meine Empfehlung diesen Schritt nicht zu gehen (und so wird das auch den Kunden weitergegeben).

Ausgetauscht werden muss "Direct Oracle Access 4.1.1" durch das SQL-Server Pendant. Desweiteren muss im Source entsprechende Oracle-Objekte ausgetauscht werden (ist klar diesen Aufwand muss ich selbst abschätzen weil nur ich den Source kenne). TQuery,etc. werden nichts benutzt. Läuft alles über die Packages und dann eben die erwähnten Oracle-Objekte mit deren Hilfe dann die Daten auf die GUIs gebracht werden.

Da eine Neuentwicklung nicht in Frage kommt (Die Anwendung ist so ja OK und eigentlich auch gepflegt aber Oracle eben anscheinend zu teuer im Betrieb (?)) wollte ich wissen wie einfach es ist eine bestehende Anwendung von Oracle auf SQL-Server zu trimmen (ohne Anpassungen am Source, nur der technische Switch) und dann die Möglichkeit einzurichten damit theoretisch Prozeduren auf dem MS-Server angesprochen werden können.