Jackery IFA Fireplace
Mobile

C# Middleware zwischen verschiedenen Datenbanksystemen

-=Renegade=-

Lt. Junior Grade
Registriert
Nov. 2006
Beiträge
436
Hallo,


Da ich gerade von Oracle auf eine MySQL Datenbank zugreifen muss, dachte ich mir, es wäre ganz nützlich, einen generischen Ansatz zu verfolgen, um nicht jedes mal die Kommunikation hard-codiert implementieren zu müssen.

Zumindest in PL/SQL, also Oracle, ist es relativ einfach, DLLs etc. einzubinden. Die Idee wäre also, den Befehl als Parameter einer C# Funktion an die andere Datenbank zu schicken und einen Cursor / Dataset als Rückgabewert zu bekommen.

Unsicher bin ich mir allerdings etwas bei der Realisierung des C# Teils:
DB Zugriff empfiehlt sich wohl mit ADO.NET ? (Hab damit noch nicht gearbeitet)
Wie kann man den Return Value am besten realisieren, so dass es dann auch PL/SQL versteht? Dataset --> SYS_REFCURSOR?!


Vielen Dank im Voraus für Ideen,

so long
 
Ich würde bei sowas immer eine Kommunikationskomponente verwenden.
Also eine Klassenbibliothek die die ganze Kommunikation mit der Datenbank abwickelt.

Das eigentliche Programm nutzt dann nur eine standardisierte API (siehe Interfaces).
Kommt MySQL zum Einsatz, verwendet das Programm die MySQL-Komponente, kommt Oracle zum Einsatz wird die andere Komponente verwendet.

Wenn man z.B. aus beiden Datenbanken Personen laden möchte, definiert das Interface dafür die Funktion
GetPerson(). Die Funktion selbst wird dann in der MySQL-, sowie in der Oracle-Komponente mit den passenden SQL-Befehlen implementiert.
 
Hallo,

Danke für deine Antwort. Ich glaube, ich hab das Problem etwas schlecht beschrieben. Mir geht es nicht darum, ein standardisiertes Interface für verschiedene Datenbanksysteme zu erstellen, sondern direkt eine Kommunikation zwischen den DBs (kein bidirektionaler Weg, also es besteht nicht die Notwendigkeit, einen Befehl für unterschiedliche DB Systeme auszutauschen)

Beispiel: Ich habe Daten / Informationen in einer MySQL DB abgespeichert, die ich direkt in einer Oracle DB brauche (nicht direkt für eine Applikation). Wäre es auf verschiedenen Oracle DBs, so könnte ich die Daten via DB Link auf einer DB selektieren und auf der anderen einfügen.

Zwei Ansätze: Der einfache Weg (kein Problem) wäre, ein C# Programm zu schreiben, welches sich zur MySQL DB verbindet, die Daten selektiert, sich dann zur Oracle DB verbindet und die Daten dort reinschreibt. Nachteil: Brauche ich in Zukunft andere Daten, muss ich jedesmal eine neue Routine implementieren. Da es hier wirklich rein um die direkte Kommunikation zwischen zwei Datenbanken geht, relativ umständlich.

Der kompliziertere, generische Ansatz (wobei ich hierbei für andere Überlegungen natürlich offen bin): Eine DLL, welche in Oracle (PL/SQL) eingebunden wird, welche einen beliebigen SQL Befehl als Parameter übernimmt und das entsprechende DataSet beispielsweise als SYS_REFCURSOR zurückliefert. Intern, also in der C# Komponente, würde dass dann etwa so ablaufen (Pseudocode)

Code:
public DataSetDataType genericSQL(String sqlCommand) {
    // Verbindung zur DB
    // Sende SQL Command
    // Return Data Set
}

Die Frage die halt bleibt ist, empfiehlt sich für den DB Zugriff ADO.NET (oder eine eigene Klasse für jede DB Connection über ein Interface, da würde es schon Sinn machen)
Und wie kann ich einen Cursor / DataSet Datentyp zurück geben, den ich mit PL/SQL im Sinne eines SYS_REFCURSOR oder ähnlich verarbeiten kann.



so long
 
Zuletzt bearbeitet:
Ach so. Du möchtest sozusagen eine Erweiterungs-DLL haben, die dir eine Funktion zur Verfügung stellt um beliebige SQL-Befehle aus Oracle direkt an MySQL zu schicken und erwartest als Antwort eine Referenz auf den Cursor des Resultsets?

Vorneweg: Kann Oracle denn überhaupt .NET-DLLs laden oder nur nativen Code?
Die DLL die du bei CSharp rausbekommst ist ja keine native DLL, sondern bloß ne .NET Assembly.
Weiß nur dass der MS-SQL Server sowas verwenden kann, weil der eine Common Language Runtime-Integration hat. Aber Oracle?!?
 
Argh, guter Einwurf, da hab ich wieder zu schnell gedacht :(

Ich werd mal schaun, aber logisch wär eig. nur native
 
Zurück
Oben