DB-Funktionen von MSSQL in Oracle nachbauen

[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')

[Delphi.Narium]

Frage:

In welcher Form liegen die alten SQLs vor?

Alle irgendwie einzeln?

In einer Textdatei und der Anwender sucht sie sich da raus?

Im Quelltext irgendeiner oder mehrere Anwendung(en)?

Bin in der Vergangenheit recht gut damit gefahren, die SQLs in 'ner Datenbanktabelle vorzuhalten.

Da kann man dann eine Spalte für die MSSQL-Syntax machen, eine Spalte für die Oracle-Syntax u.s.w. für alle zu unterstützende Datenbanken.

Jede Zeile der Tabelle hat 'ne eindeutige ID.

Die Software, die die SQLs braucht, kennt dann nur noch diese ID und weiß um welche Datenbank es sich handelt.

Soll also ein SQL ausgeführt werden, holt sie sich per ID und Info zur verwendenen Datenbank das passende SQL aus der Tabelle, versorgt es ggfls. mit Parametern, und führt es aus.

Oder man macht für jede Datenbank 'ne View, die dann nur die ID und die SQL-Spalte der entsprechenden Datenbank liefert. Dann muss die Software nur die ID wissen, gegen welches DBMS sie dann läuft, ist für die Software "wurscht". Sie sieht nur, was sie konkret benötigt.

Oder man macht je DBMS eine Tabelle und nutzt dann dort immer das datenbankspezifische Befüllscript.

Ist eigentlich recht pflegeleicht und wenn man das einmal in 'ner Anwendung drinne hat, muss die Anwendung bei Änderungen am SQL nicht jedesmal angepasst werden.

Wird 'ne weitere Datenbank unterstützt, bekommt die Tabelle 'ne weitere Spalte und die Software kann dann die SQLs dort herholen.

Die Pflege der Tabelle kann man dann jemandem anvertrauen, der sich in der SQL-Welt gut auskennt und weiß, wie man die einzelnen Datenbankspezialitäten am besten übersetzt bzw. wie man es hinbekommt, dass sich die SQLs zwischen den einzelnen Datenbanken nicht mehr so gravierend unterscheiden.

Im Idealfall ist das für die die SQLs nutzende Software absolut transparent.

Der erstmalige Aufbau eines derartigen Konzeptes kann schon ziemlich viel Arbeit sein, die sich aber in der Regel auch recht schnell amortisiert.

[jobo]

1) Implizite Datumskonvertierung geht leider auch in Oracle, das ist nur eine Frage der passenden locale settings in der session. Ich würde versuchen das alles zu finden und durch explizite Konvertierung mit Maske auszutauschen. Aber notfalls tut es auch die adaptierte Standardeinstellung für Datumsmaske im client oder sogar in der session.

2) Oracle + Joins würde ich ebenfalls in die Tonne treten, das ist ja auf jeden Fall etwas, womit Du nur gewinnen kannst. Die Standard Join Syntax ist kompatibler, mächtiger und bestimmt seit einiger Zeit auch sicher besser supported (Bugs, Optimizer, …)

Hier sind ein paar Links, die Idee eines Kompatibilitätspackages findet man im Netz interessanter Weise nicht.
https://www.oracle.com/database/tech...to-oracle.html
(wie das Teil mit den MS Funktionen umgeht, weiß ich nicht)

Für 11
https://www.oracle.com/webfolder/tec...server_otn.htm
Auch hier brauchst Du ja nur einen Teil..

http://www.sqlines.com/sql-server-to...-sql-functions
Wie vollständig das ist, schwer zu sagen, isnull() fehlt z.B.

Angenommen, Postgres ist nahe an Oracle (spätestens mit compatibility extension) kann man auch mal hier drauf schauen:
https://severalnines.com/database-bl...ou-should-know
https://wiki.postgresql.org/wiki/Mic...by_Ian_Harding

[Jumpy]

Zitat von Delphi.Narium:

Frage:
In welcher Form liegen die alten SQLs vor?

In einer (lokalen?) Datenbank, die aber nicht bei uns liegt. Ist vllt. ein Ansatz den man auch verfolgen kann, ob man nicht die gespeicherten SQL-Statements selber irgendwie updated. Aber dazu muss ich da erst mal Zugang zu bekommen.

Zitat von Jobo:

die Idee eines Kompatibilitätspackages findet man im Netz interessanter Weise nicht.

Das ist genau das, was ich auch gesucht habe und nicht finden konnte. Darum der Thread hier, da ich gehofft habe, dass zumindest andere Suchbegriffe als Stichworte durch eure Hilfe aufkommen. Aber wenn du da nichts finden kannst, beruhigt mich das zumindest in soweit, als das ich nicht zu blöd zum googlen bin .
Danke für die Links, da schau ich mal ob Zwischendurch was genannt wird, was mir einen Tip gibt.

[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

[jobo]

Ich vermute, sowas gibt es nicht, weil es sich nicht "lohnt". Das liegt vielleicht einerseits an der geringen Zahl von nicht passenden Funktionen, andererseits daran, dass die Migration Software von Oracle persönlich existiert und ihre Sache vielleicht gut macht. Also wirklich SQL umschreibt, bspw., Type Mapping macht usw.
Richtig verstanden?:
Die Statements befinden sich in einer DB, also nicht als Views, sondern als Datensätze in Textform?
Das Problem an der Datenbankmigration dürfte sein, dass sie nur Dinge konvertiert, die Bestandteil des DM sind, also DB Objekte. Also müsste man die Statements m.E. am besten in Views umwandeln. Dann die Konvertierung anwerfen und die Views später wieder zurück führen.