[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:

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:

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:

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:

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:

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.

[Bernhard Geyer]

Zitat:

Zitat von alzaimar

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) ...

Gibts noch mehr? :gruebel: Ah ja. Delete fehlt noch :-) Nicht zu ernst sehen - 1/2 Flasche Rotwein :???:

Zitat:

Zitat von alzaimar

Die Schwächen von ADO kann man hier vernachlässigen. Der Vorteit: ADO ist eigentlich auf jedem PC drauf.

Na ja. Eigentlich nur für den MS-SQL-Server. Access wird von MS eh schon in die 2te-Reihe gestellt und der Oracle-Provider ist soweit ich beurteilen kann ein Witz. Dann schon lieber Zeos (Setzt ja bei MS SQL-Server auch auf ADO auf). DBExpress könnte nachdem Codegear mit Delphi 2007 endlich DBExpress und BDP vereint hat (muß es nicht CDP heißen :gruebel:) auch ne gute alternative werden.

[ice.icewing]

Die Systeme unterscheiden sich schon ganz ordentlich. Besonders aufgefallen ist mir das bei Feldern die mit Datum und Uhrzeit zu tun haben. Hier blos mal der Anweisungsausschnitt für insert in ein DateTimefeld.

Delphi-Quellcode:

case RG1.ItemIndex of
  0 : TempString:=TempString+'To_Date('
      + QUOTE + FormatDateTime('YYYY-M-D h:nn:ss', Fields[J].AsDateTime)
      + QUOTE + ', ' + QUOTE + 'YYYY-MM-dd HH24:MI:SS' + QUOTE + ')';
  1,2 : TempString:=TempString+QUOTE+AnsiDateTimeToStr(Fields[J].AsDateTime,True)+QUOTE;
  3 : TempString:=TempString+QUOTE+FormatDateTime('D.M.YYYY h:nn:ss', Fields[J].AsDateTime)+QUOTE;
end;

(0=Oracle, 1=MySQL, 2=InterBase, 3=MSSQL)

Weitere Unteschiede sind die Datentypen. Das ist aber vor allem bei Createanweisungen interessant.
Der Umgang mit Autocommit ist verschieden. Bei MSSQL standardmässig an und man macht "Begin Transaction" wenn man es mal nicht will. Bei MySQL sagt man "Set Autocommit = 0"
Auch Autoincrement wird ganz verschieden gehandhabt. Bei Oracle mit Sequence und Trigger ,bei Interbase mit Generator und Trigger, bei MySQL mit AUTO_INCREMENT und bei MSSQL mit IDENTITY. Und verhalten tun sie sich auch noch unterschiedlich.

Da PlugIn und DLL ja schon da also würde ich vom Einsatz eines (jedenfalls für mich) komplizierten Bridge Pattern absehen. Die SQL-Anweisungen solltest du aber jeweils in deinem Plugin aus entsprechenden Übergabeparametern zusammenbauen.

Wenn du eine geniale Lösung findest lass es mich wissen.

icewing