oracle abfragen nach mysql

[hade0011]

hallo,
bitte entschuldigt diese anfängerfrage, ich hab mit datenbanken nix am hut, muss aber fürs studium ein paar oracle abfragen in mysql umwandeln. hat jemand vielleicht eine gegenüberstellung der sich entsprechenden befehle oder ähnliches? google hat mir nur programme angeboten, die ganze datenbanken umziehen können.

danke schonmal,
dennis

[mirkom76]

Du solltest Dich darauf konzentrieren, dass Du den SQL-92 Standard verwendest. Jede Datenbank hat Ihre eigenheiten. Deswegen solltest Du darauf achten, dass Deine Abfragen nicht vom Standard abweichen.

[dimitri]

Deswegen solltest Du darauf achten, dass Deine Abfragen nicht vom Standard abweichen.

Was theoretisch enorme Einschränkungen mit sich bringt und praktisch kaum möglich sein dürfte. Man betrachte nur mal die Unterschiede bei TOP, Limit oder Rownum. Dann die verschiedenen Datumsfunktionen etc.
Diese Forderung ist fast so alt wie die Legende von der Datenbankunabhängigen Anwendung.

Wenn ich SQLs von a nach b konvertieren muss, dann muss ich auch beide Dialekte kennen.

Dim

[mirkom76]

Eine andere möglichkeit ist die Verwendung eines O/R Mappers. So löse ich das Problem. Somit muss ich mich nicht mit den Dialekten einer Datenbank auskennen. Das sollte der O/R Mapper für mich übernehmen.

[dimitri]

Das sollte der O/R Mapper für mich übernehmen.

Genau und wehe man muss mal die Application/Programmiersprache wechseln. Dann ist das grosse Zähneklappern angesagt. Applicationen haben sich nach den Daten zu richten und nicht umgekehrt, denn ersteres überlebt letzteres im allgemeinen um ein vielfaches.

Dim

[mirkom76]

Wenn sich die Programmiersprache ändern sollte, kommen wesentlich mehr Probleme auf einen zu als nur die Datenzugriffsschicht.

Verbreitete Tools setzen sich in mehreren Sprachen durch. Hibernate von Java zu NHibernate in .NET ist da nur ein Beispiel.

Zittern ist nicht angesagt. Sollte kein O/R Mapper in einer völlig neuen Sprache vorhanden sein, dann baut man eben diese Schicht manuell auf.

Es scheint mir eher das Problem zu sein, dass Datenbankunabhängigkeit ein grösseres Problem darstellt. Klar gibt es Projekte, die auf eine bestimmte Datenbank aufsetzten.

Im Produktgeschäft sieht die Realität dann doch etwas anders aus. Genau hier ist Datenbankunabhängigkeit wichtig. Schließlich soll der Kauf nicht an einer nicht unterstützten Datenbank scheitern. Da sollte man eher auf den Standard achten.

Ein Standard wird genau aus dem Grund definiert um einen gemeinsamen Nenner zu finden.

[dimitri]

Ein Standard wird genau aus dem Grund definiert um einen gemeinsamen Nenner zu finden.

Nur, dass viele von Datenbanken gebotene und auch benötigte Features überhaupt nicht im Standard abgebildet sind.

Wir hatten z.B. mal das Problem für Sybase und Oracle entwickeln zu müssen. Allein die Tatsache, dass unter Oracle einfach viel mehr möglich war wenn es um Outer Joins und Subselects ging erschwerte das ganze schon ungemein.

Dann noch das unterschiedliche Verhalten bei Transaktionen. Sowohl MSSQL als auch Oracle implementieren ACID Transaktionen trotzdem ist das Verhalten beider Datenbanken komplett unterschiedlich (in oracle wird z.B. nie ein SELECT von einer DML Änderung geblockt und umgekehrt, ebenso wenig gibt es dirty reads).

Eine umfangreiche AW für mehrere Datenbanksysteme zu schreiben ist sehr aufwändig, fehleranfällig und bringt einen erhöhten Testaufwand mit sich (z.B. Bugs die in DB X einen Workaround benötigen treten in DB Y nicht auf etc.).

Ich für meinen Teil bin froh, dass wir keine O/R Mapper verwenden der Objekte nach seinem gutdüncken ablegt sondern das gute alte relationale Modell welches von jedem Programm in jeder Programmiersprache gelesen und geschrieben werden kann.

Dim

[mirkom76]

Okay, ich verstehe Dein Problem. Es gibt natürlich unterschiedliche Ansätze von O/R Mappern. Die einen erstellen die Datenbankstruktur aus dem Objektmodell und die anderen generieren die Entities aus dem bestehen
den Datenmodell.

Ich für meinen Teil bevorzuge das generieren der Entities aus dem Datenmodell heraus.Das Datenmodell ist der Master. Schliesslich muss man in der Lage sein die Datenbank optimieren zu können, falls z.B. Performance-Probleme auftreten. Das geht bei ersten Varianten meiner Meinung nach wesentlich schwieriger.