Package bauen war auch mein erster Gedanke. Man hat braucht nur eine Stelle, an der man ergänzen, erweitern, Fehler korrigieren muss. Synonyme auf die einzelnen Routinen des Packages. Danach sollte die ganze "Übersetzungsgeschichte" recht transparent und pflegeleicht sein.
Im Idealfall werden vom Kunden, wenn er denn mal an die "
MSSQL-Erbstücken" ran muss, diese auf Oracle (besser
SQL-Standard) umgeschrieben, so dass das "Übersetzungspackage" und die Synonyme im Laufe der Zeit obsolet werden.
Andererseits: Wenn Ihr sowieso Richtung Postgres schielt, wäre eventuell die Packagelösung die sinnvollste.
Jetzt baut Ihr eins für Oracle. Später eins für Postgres.
(
PostgreSQL 7.3.21 Documentation - Porting from Oracle PL/SQL)
Wenn das gut gelingt ist es für die Kunden-
MSSQL-Altlast jetzt bei Oracle, später bei Postgres, transparent und Ihr müsst euch um dass, was der Kunde bisher gezaubert hat und in Zukunft noch zaubern wird, keinen Kopp machen. Und wenns irgendwann mal wieder zurück nach
MSSQL geht, muss sich auch keiner Gedanken machen.
Viel blöder find ich in diesem Zusammenhang eher so Sachen wie
SQL TOP, LIMIT or ROWNUM, die kann man nicht "so mal eben" durch 'ne Ersatzfunktion "überbügel", ohne dass es jemand merkt.
Da muss man dann wohl die passenden SQLs schlimmstenfalls je zu nutzendem
DBMS separat vorhalten. Das ist nicht wirklich witzig und ziemlich pflegeaufwändig.