DB-Funktionen von MSSQL in Oracle nachbauen

[Bernhard Geyer]

Zitat von DasWolf:

COALESCE ist der SQL-Standard und funktioniert bei beiden DBMS.

Coalesce war bei uns einer der Gründe das wir mit neueren Versionen der Anwendung definitiv kein alte Oracles mehr unterstützen, welche kein Coalesce können.

[himitsu]

ISNULL als Funktion() oder als Operator?

Postgres kennt auch sowas (x IS NULL, x IS NOT NULL, x ISNULL und x NOTNULL),
aber der Operator ließe sich im SQL-Export/Backup ja problemlos String-Replacen,
anstatt unnötig aufwändig diese Funktionen nachzubauen.

"ISNULL(" -> "COALESCE("
"NOT ISNULL" -> "IS NOT NULL"
"NOTNULL" -> "IS NOT NULL"
"ISNULL" -> "IS NULL"

Oracle kann kein COALESCE?

Zitat:

COALESCE ist der SQL-Standard und funktioniert bei beiden DBMS

klang so, als wenn wenigstens das ging

[Jumpy]

Zitat von himitsu:

ISNULL als Funktion() oder als Operator?

Als Funktion ala "Wenn das Feld Null ist dann ersatzweise dies hier".

ISNULL war jetzt auch nur Beispielhaft genannt.

[jobo]

Ich würde ein separates Package bauen, wo alle MS-SQL Funktionen (Prozeduren werden es wohl nicht sein) angelegt werden, die man braucht.
Das Teil dann Public setzen in der Hoffnung, dass nichts kollidiert -wenn ja, hat man vielleicht ein schlimmeres Problem- und dann muss der Kram laufen.
Das geht natürlich so wirklich nur für Funktionen, nicht für SQL Befehle, sagen wir mal wie z.B. - connect by prior von Oracle hier, kenne aus dem Stand keine derartigen MSSQL Geschichten.
Es gibt ja vielleicht auch diverse "Success" Stories, in denen solche Compatibility Packages bereits entstanden sind, einfach mal githuben oder auch so in der Wildnis nach solchen Geschichten suchen. Nicht zuletzt die Hersteller selber blasen ja gern jede derartige Nummer zu den genannten Stories auf und helfen dem Kunden ggf sogar dabei.

[jobo]

Kleiner Denkfehler, Public bedeutet ja nicht, dass der Package Name obsolet ist.
Also entweder gleich separate (eigenständige) Functions oder die Package Functions vielleicht mit Synonyms versehen.

Oder halt die MS-SQL spezifischen Functionsaufrufe mit <oracleersatzpackagename>.<ersatzfunktion> ersetzen.
Bei einer endlichen Anzahl N von fehlenden Ersatz Funktionen, wäre es auch nicht mehr als N mal Suchen /Ersetzen im ursprünglichen MS Code.

[Delphi.Narium]

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.

[Jumpy]

@Jobo: Es geht nur um Funktionen.

Die Package-Lösung klingt sinnvoll. Ich versuche mal weiter im Netz was fertiges dazu zu finden, dass man ggf. anpassen kann. Wenn das nichts wird, bauen wir uns da halt was eigenes und erweitern das nach und nach.


Mir sind mittlerweile in den SQL-Statements auch ein paar andere Schoten aufgefallen, wo es wahrscheinlich nicht anders geht, als die betroffenen Statements anzupacken, aber vielleicht hat da ja auch noch einer eine Idee:

1) Ein Datum als String wird in MSSQL zum Teil automatisch in ein Datum konvertiert und kann für Vergleiche genutzt werden. In Oracle brauch ich da immer ein To_Date() drum.

2) Zum Teil alte SQL-Syntax bei Joins mit den (+) Geschichten. Da dürfen bei Oracle solche Felder nicht im Zusammenhang mit dem "Or" oder "in" Operator benutzt werden. War mir neu, benutz die alte Syntax aber selbre auch kaum. Bei MSSQL scheint das wohl zu gehen. Sinngemäßes Beispiel:

SQL-Code:

Select irgendwas From Tabelle1, Tabelle2
Where
  Tabelle1.Feld = Tabelle2.Feld(+)
  and (Tabelle2.Nachname(+)='Müller' or Tabelle2.Nachname(+)='Maier')

[mschaefer]

Moin zusammen,

einiges kann man per Oracle-Function nachbauen. Coalesque gibt es meine erachtens auch bei 11g schon, aber das waere auch ueber eine Funktion kein Problem. Diese isnull Sachen gehen wahrscheinlich nicht nachzubauen. Es werden einem die Freuden der Migration daher einholen.

Grüße in die Runde

Martin