Datenbankunabhängigkeit (Umwandlung ODBCCommand zu anderen Commands)

Question

Hallo zusammen,

ich sitze hier an einem Problem, dass ich gerne mal mit ein paar Profis durchsprechen würde.

Ich habe folgendes Konstrukt:

Meine Software arbeitet mit ODBCCommands. Diese Commands werden an eine .dll übergeben, die die Kommunikation zu der Datenbank übernimmt. Da habe ich folgendes Bild im Kopf:

In dieser .dll würde ich gerne die ODBCCommands in die jeweiligen Clients umwandeln (Oracle oder SQL Server).
d.h. ich möchte dem Kunden die Software ausliefern und die zu seiner Datenbank passende .dll.

Ich erhoffe mir dadurch eine gute Lösung, um eine Datenbankunabhängigkeit hin zubekommen. Nun zu meiner Frage: Ist das Konstrukt so OK, oder gibt es da Bessere bzw. geht es schlicht und ergreifend einfach nicht, so wie ich mir das vorstelle.

Vielen Dank.

---

Vielen Dank und Gruß Martin

Answer 1

Hallo Martin,

Das Schreiben anbieterunabhängigen Datenbankanwendungen ist alles andere als trivial. Schön wär's wenn die Umwandlung von OdbcCommands so einfach wäre, wie Du dir das vorstellst. Ist es aber nicht. Als Einstieg würde ich dir vorschlagen hier zu beginnen:

Übersicht über das Factorymodell (ADO.NET):
http://msdn.microsoft.com/de-de/library/cy5kfe3c.aspx

Aber auch hier steckt oft der Teufel im Detail. Denn schon die CommandText-Anweisungen sind zwischen Datenbanken nicht immer kompatibel, da müßtest Du schon auf dieser untersten Ebene konvertieren. Oracle geht mit dem Autoinkrementieren anders um als der SQL Server, benutzte Funktionen heißen manchmal ganz anders oder es gibt jeweils Sonderwege.

Wenn Du den pragmatischen Ansatz nehmen willst, würde ich dir empfehlen mal ein Auge auf EntitySpaces zu werfen. Es unterstützt 10 Datenbankengines, ist äußerst flexibel und kostet nicht die Welt.

Gruß
Marcel

Answer 2

hmm. Nicht gut.

EntitySpaces muss ich mir mal genauer anschauen. Ich hatte gehofft "einfach" den SQL umzusetzen und den entsprechenden Command damit zu füllen. Die Parameter müssten umbenannt und neu gefüllt werden und dann passt das.

Aber schon allein beim SCOPE_IDENTITY() gibt es goße Differenzen zwischen SQL Server und Oracle.

Danke für die Infos.

---

Vielen Dank und Gruß Martin