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.