Wie viel Kompatibilität haben die DB-Engines auf SQL-Ebene?

Question

Nehmen wir an, ich wollte eine Anwendung haben, die die DB am Back-End leicht wechseln kann.
Ich denke vor allem von SQL Server als primäre Back-End, aber mit der Flexibilität, eine andere DB-Engine zu gehen. Firebird und PostGreSQL scheinen (aus meiner kurzen Wikipedia-Exkursion) die meisten Gemeinsamkeiten mit SQL Server zu haben (plus sie sind kostenlos).

Wie ähnlich wären die DB-Einrichtung, der Zugriff, die Abfragen, etc. für Firebird, PostGreSQL und MS SQL Server?

Answer 1

Leider ist SQL von Anbieter zu Anbieter sehr unterschiedlich. Es ist fast unmöglich, nur das trivialste SQL zu schreiben, das auf einer Reihe von RDBMS ausgeführt werden kann - und dann befindet man sich im Bereich des kleinsten gemeinsamen Nenners. Viel besser ist es, eine Abstraktionsschicht zu verwenden, die zumindest die Verbindung zur Datenbank (inkl. Zugriff, Senden von Abfragen) handhabt, und entweder ein ORM, um die SQL selbst zu handhaben, oder SQL pro Anbieter.

Gute Beispiele sind das automatische Erhöhen von IDs und das Ermitteln der ID des zuletzt eingefügten Datensatzes.

Answer 2

Ich habe an einem Projekt gearbeitet, bei dem die Unterstützung zahlreicher Datenbanken, darunter mindestens Access, SQL Server und Oracle, eine absolute Notwendigkeit war.

Ich weiß also, dass es machbar ist. Die meisten DMLs (SELECT, UPDATE, INSERT...) sind gleich, und wir hatten keine großen Probleme, sie in allen Datenbanken zum Laufen zu bringen - nur gelegentliches Ärgernis. MySQL war damals die Ausnahme, da es einfach nicht leistungsfähig genug war.

Die meisten Unterschiede fanden wir in der DDL, aber mit der richtigen Architektur (die wir hatten) war es nicht schwer, diese zu beheben.

Das Einzige, was uns Probleme bereitet hat, war die Generierung eindeutiger IDs - Autoinkrement ist kein Standard. Glücklicherweise gab es in einer Datenbank mit etwa 40 Tabellen nur wenige Stellen, an denen eindeutige IDs erforderlich waren (gutes DB-Design). Letztendlich generieren wir die eindeutige ID im Code und behandeln alle Konflikte (alles in Transaktionen).

Es hat die Dinge einfacher gemacht, weil wir es vermieden hatten, Autoinkrement für ID-Felder zu verwenden, es ist schwieriger, an eindeutige Schlüssel zu denken - aber auf lange Sicht besser.

Answer 3

Nun, CRUD-Zeug sollte überall gleich sein, aber wenn Sie etwas Komplexes bauen, werden Sie wahrscheinlich Trigger und gespeicherte Prozeduren verwenden wollen, und das ist, wo die Kompatibilität gering wird. Das Schreiben einer DBMS-agnostischen Anwendung bedeutet in der Regel die meisten der Geschäftslogik außerhalb der Datenbank zu verschieben, so dass eine 3-Tier-Anwendung ist, IMHO, ein Muss in einem solchen Fall.

Alternativ könnten Sie eine Wrapper-Bibliothek verwenden, die wie eine Abstraktionsschicht funktioniert, aber ich habe noch keine gesehen, die in der Lage ist, die Aufgabe korrekt über eine Reihe von DBMS-es zu erledigen. Natürlich hängt das auch von der Programmiersprache ab, die Sie verwenden.

Answer 4

Wie bereits in den anderen Antworten erwähnt, variieren DBMS stark, sobald man über die grundlegenden SELECT/INSERT-Funktionen hinausgeht (und manchmal sogar dort).

Außerdem müssen wir die Kompatibilität zwischen verschiedenen DBMS aufrechterhalten. Meiner Meinung nach ist es am besten, eine Art Kompatibilitätsschicht zu verwenden. Wir haben eine hauseigene DB-Abstraktionsbibliothek, aber es sind auch andere Tools verfügbar.

Insbesondere könnte es sich lohnen, die gängigen ORMs (Hibernate, nHibernate usw.) zu betrachten. Sie bieten in der Regel DB-Unabhängigkeit als eine Art Nebeneffekt. Zumindest Hibernate hat auch eine spezielle Abfragesprache, die automatisch in SQL für das von Ihnen verwendete DBMS übersetzt wird.