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

Question

Nehmen wir an, ich wollte eine Anwendung, die leicht die DB auf dem Back-End wechseln könnte.
Ich denke vor allem von SQL Server als primäre Back-End, aber mit der Flexibilität einer anderen DB-Engine zu gehen. Firebird und PostGreSQL zu haben scheinen (aus meiner kurzen wikipedia Exkursion) die gemeinsam w / SQL Server (und sie sind frei).

Wie ähnlich würde der DB-Setup, Zugang, Abfragen, etc .. sein für Firebird, PostgreSQL und MS SQL Server?

Answer 1

ich an einem Projekt gearbeitet, wo es eine absolute Voraussetzung war viele Datenbanken zu unterstützen, zumindest einschließlich Access, SQL Server und Oracle.

Also ich weiß, dass es getan werden kann. Meist DML (SELECT, UPDATE, INSERT ...) ist das gleiche und sicherlich hatten wir keine großen Probleme, die sie über alle Datenbanken zu machen arbeiten - nur gelegentlich Belästigungen. MySQL war die Ausnahme zu dieser Zeit, da es einfach nicht genug fähig war.

Wir fanden die meisten Unterschiede in den DDL, aber mit der richtigen Architektur (was wir hatten), war es nicht schwer, dies zu beheben.

Das einzige, was uns verursacht ein Problem einzigartig ids wurde Erzeugung - autoincrement ist Nicht-Standard. Fortuantely in einer Datenbank von rund 40 Tische waren es nur wenige Orte, an denen eindeutige IDs waren notwendig (gut DB-Design). Am Ende haben wir die eindeutige ID im Code erzeugen und verarbeiten alle mögliche Auseinandersetzungen (alles in Transaktionen).

Es hat die Dinge einfacher, weil wir mit Autoinkrement für ID-Felder vermieden hatte, es schwieriger ist, der eindeutige Schlüssel zu denken -. Aber besser auf lange Sicht

Answer 2

Leider variiert SQL weit über Anbieter. Es ist fast unmöglich, alle, aber die meisten trivial SQL zu schreiben, auf eine Reihe von RDBMS zu laufen - und dann sind Sie in kleinsten gemeinsamen Nenner Gebiet. Weit besser eine Abstraktionsschicht zu verwenden, zumindest die Verbindung zur Datenbank zu behandeln (inkl. Zugang, Abfragen zu senden) und entweder ein ORM des SQL selbst zu behandeln oder pro-Provider SQL.

Wenn Sie in aussehen wollen, wie sie variieren -. Gute Beispiele hierfür sind mit automatischer Erhöhung ids und die ID des zuletzt eingefügten Datensatz zu erhalten

Answer 3

Nun, sollten CRUD Sachen überall gleich sein, aber wenn man etwas komplexer bauen, werden Sie wahrscheinlich wollen Trigger und Stored Procedures verwenden, und das ist, wo die Kompatibilität gering. Schreiben eine DBMS-unabhängige Anwendung in der Regel bedeutet, die meisten von der Business-Logik außerhalb der Datenbank zu bewegen, so mit einer 3-Tier-Anwendung ist, IMHO, ein Muss in diesem Fall.

Alternativ können Sie eine Wrapper-Bibliothek verwenden, wie Abstraktionsschicht funktioniert, aber ich bin noch ein, um zu sehen, dass der Job richtig über einen Bereich von DBMS-es tun kann. Natürlich, das auch abhängig von der Programmiersprache, die Sie verwenden.

Answer 4

Wie die anderen Antworten darauf hingewiesen, DBMS variiert wild, wenn Sie über grundlegende SELECT / INSERT Sachen gehen (und manchmal sogar dort).

Wir müssen auch Unverträglichkeiten über mehrere DBMS halten. Meiner Meinung nach ist der beste Ansatz in der Regel eine Art von Kompatibilitätsschicht zu verwenden. Wir haben eine hauseigene DB Abstraktions-Bibliothek, aber es gibt mehrere Tools zur Verfügung.

Insbesondere könnte es zahlen bei beliebten ORMs (Hibernate, nHibernate etc.) zu suchen. Sie bieten in der Regel DB-Unabhängigkeit als eine Art Nebeneffekt. Mindestens Hibernate hat auch eine spezielle Abfragesprache, die automatisch übersetzt wird für das DBMS SQL Sie verwenden.