Das mit der Unterstützung mehrerer Datenbanken ist eine eigene Wissenschaft. Wenn es geht, würde ich das immer vermeiden!
Ich würde es immer Anstreben. Unsere SW wird bei Firmen eingesetzt und dort ist es ungünstig wenn man ein
DBMS erfordert das nicht schon im Haus eingesetzt wird. Entweder würde man den Auftrag nicht bekommen oder man hätte den kompletten Support der
DB an Hals. Sprich: Einrichtung+Pflege Backup, Sicherungstrategie, ...
All das kann man vermeiden indem man die "üblichen"
DBMS unterstützt und der Kunde dann das einfach auf eine bestehende
DB aufsetzt.
Eine Multi-
DBMS-fähige Zugriffsschicht ist nur ein kleiner Teil des Puzzles. Da kommen dann noch unterschiedliche Datentypen der
DBMS, Trigger, SP, verschiedenes Verhalten bei UNIQUE-Constraint, Transaktions-Handling etc. Die Ganzen
DB-Strukturen müssen dann synchron gehalten werden, d.h. generell ist auch ein viel höherer Wartungsaufwand notwendig.
Wir haben es sogemacht das wir einerseitzt diverse Elemente nicht unterstützen und dann zur Vereinfach nach Bridge-Pattern-Muster Klassen angelegt haben. So ist dann der
DB-Spezielle Teil nur noch ca. 2.000 Quellcodezeilen lang. Der Rest der mehreren 100.000 Quellcodezeilen setzt auf eine
DB-Neutrale
API auf.
Es muss dann auch noch für jede
DBMS getestet werden.
Hier bietet sich
Unit/Modultests an. Einmal definiert müssen diese fü alle
DB-Module gleich durchlaufen. Ist also nur minimal mehr Aufwand.