[SQL] In wie weit sind SQL Datenbanken kompatibel?

[gsh]

Hi DPler

Ich hab mal eine Frage wegen SQL-Datenbanken. In wie weit sind die ganzen SQL-Datenbanken mit den SQL-Befehlen Kompatibel?
Also mir gehts um vorallem diese Datenbanken: MySQL, MSSQL, Oracle, Microsoft Access, SQLLite und vllt. auch Firebird

Zu meiner Problematik:
Ich hab ein Programm geschrieben das mehere Datenbanken unterstützen soll. Dies macht es über DLLs die Plugin mäßig eingebunden werden. Diese Datenbank Plugins erledigen also die komplette Kommunikation mit den Datenbanken. Das Programm kriegt also nicht mit mit welcher Datenbank eigentlich kommunitiert wird. Dem Programm ist es auch ziemlich egal da es die SQL Befehle einfach dem Plugin übermittelt und die daten dann vom Plugin zurückbekommt.

So aber auf was muss ich jetzt aufpassen.
Eins hab ich schon bemerkt und zwar mit " und ' Mysql kann beides Oracle kann nur '. Deshalb muss ich jetzt aufpassen das ich überrall nur ' in den SQL Statments verwende.

Was muss ich noch beachten?
Was könnten für probleme auftreten?

[hoika]

Hallo,

das S in SQL steht nicht für Standard, sondern Strukturiert.

Die SQL-Befehle an die Plugins zu übergeben, ist keine gute Idee,
übergibt die Anfragen als Funktion/Methode,
und lass die SQL-Befehle durch die Plugins erledigen.


Heiko

[gsh]

Zitat von hoika:

das S in SQL steht nicht für Standard, sondern Strukturiert.

Die SQL-Befehle an die Plugins zu übergeben, ist keine gute Idee,
übergibt die Anfragen als Funktion/Methode,
und lass die SQL-Befehle durch die Plugins erledigen.

Aha und warum ist es keine Idee die SQL Befehle an die Plugins zu schicken?

[mkinzler]

Zitat:

Aha und warum ist es keine Idee die SQL Befehle an die Plugins zu schicken?

Weil die Datenbank-Dialekte sich z.T. stark unterscheiden. Du hast die Wahl: einen sehr kleinen gemeinsamen Nenner oder ein schnelleres System, das mehrere DBMS optimal unterstützt.

[gsh]

Zitat von mkinzler:

Weil die Datenbank-Dialekte sich z.T. stark unterscheiden. Du hast die Wahl: einen sehr kleinen gemeinsamen Nenner

hmm ja aber was ist der kleine gemeinsame nenner? wie viel spielraum hab ich?
Spezielle Datenbank-Befehle brauch ich ja nicht.
Vorrallem Insert, Update, Select

Zitat von mkinzler:

oder ein schnelleres System, das mehrere DBMS optimal unterstützt.

damit meinst du des ich die SQL-Statments in die Plugins packen soll oder?

[mkinzler]

Zitat:

damit meinst du des ich die SQL-Statments in die Plugins packen soll oder?

Ja.

[alzaimar]

ADO wurde von Microsoft als Nachfolger von ODBC mit genau diesem Ziel entwickelt: Eine einheitliche Schnittstelle für die unterschiedlichsten Datenbanken zu schaffen: Was in der Theorie so schön klingt, ist in der Praxis zum Scheitern verurteilt, eben wegen dem 'kleinsten gemeinsamen Nenner'. Damit wird so eine Schnittstelle zur lahmen Ente.

Wenn Du deine DLL nicht nur zur Übung entwickelst, sondern auch an einen Einsatz denkst, würde ich wirklich ADO verwenden (oder irgend eine andere Bibliothek, wie Zeos, DBExpress etc. ). Wozu (außer zu Lernzwecken) das Rad zweimal erfinden?

[gsh]

naja dann werd ich halt die SQL Befehle in die DLLs auslagern

Trotzdem danke

[Bernhard Geyer]

Zitat von alzaimar:

ADO wurde von Microsoft als Nachfolger von ODBC mit genau diesem Ziel entwickelt: Eine einheitliche Schnittstelle für die unterschiedlichsten Datenbanken zu schaffen

Aber nicht auf Ebene der SQL-Befehle, sondern nur auf der Ebene der Zugriffskomponenten. Und damit ist es im Prinzip nichts anderes als BDE, ODBC oder ZEOS. Aber über jede dieser "Basisschnittstellen" kann man hochperformante Anwendungen schreiben wenn man die SQL's trimmt.

Zitat von alzaimar:

Wenn Du deine DLL nicht nur zur Übung entwickelst, sondern auch an einen Einsatz denkst, würde ich wirklich ADO verwenden (oder irgend eine andere Bibliothek, wie Zeos, DBExpress etc. )

Würde ich nicht (vor allem nicht bei ADO) bzw. nicht als alleiniges Mittel. Willst du mehrer DB's unterstützen mußt du für jede DB eine spezielle Zugriffsklasse schreiben welche ADO (bei MS SQL-Server) oder Zeos oder DBExpress für den Zugriff verwendet. Jedoch muß diese Klasse die SQL-Unterschiede der DB's kapseln und nur über Higher-Level-Funktionen den Zugriff ermöglichen. Eine Realisierungsmögichkeit wäre hier z.B. die Verwendung des Bridge-Patterns.

Fertige Implementierungen die eine solche DB-Kapselung bieten wären z.B. (N)Hypernate oder bei Delphi mitgeliefert das ECO-Framework.

[alzaimar]

Hallo Bernhard,

ich gebe Dir uneingeschränkt Recht, wenn es um wirklich performante Anwendungen geht. Für die hier angefragte Funktionalität (einfache Operationen,Open,Edit,Post) reicht ADO, BDE, DBExpress, Zeos etc. imho aus. Die Schwächen von ADO kann man hier vernachlässigen. Der Vorteil: ADO ist eigentlich auf jedem PC drauf.