Komponenten zum Zugriff auf Datenbank...

[Bernhard Geyer]

Zitat von tsteinmaurer:

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.

Zitat von tsteinmaurer:

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.

Zitat von tsteinmaurer:

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.

[tsteinmaurer]

Hallo Bernhard,

das "vermeiden" kam irgendwie schräg rüber. Wenn es der Markt erfordert und man nur so wettbewerbsfähig bleibt, dann natürlich, wird man diese Richtung gehen müssen. Was ich sagen wollte ist, wenn nicht unbedingt erforderlich, dann sollte man die Multi-DBMS Sache lassen. Man braucht dafür Erfahrung in der Entwicklung und auch KnowHow über die Unterschiede der einzelnen DBMS-Produkte. SQL-Standard hin oder her, aber wenn sich dann z.B. ein Unique-Constraint in Bezug auf NULL in MSSQL zu anderen DBMS anders verhält, wirds interessant/schwierig, wenn man die Datenintegritätsregeln in der DB und nicht im anwendungsspezifischen DatenLayer haben möchte. Vor allem bei einer Zielgruppe wie von dir dargestellt (größerer Unternehmen mit eigener IT etc.), wenn man davon ausgehen kann, dass die DB ev. auch noch von anderen Anwendungen verwendet wird.

Ich kenne das eine oder andere kleinere Softwarehaus, dass sich mit der Multi-DBMS-Thematik total verrannt hat und letztendlich vom Markt verschwunden ist, weil das Produkt für kein DBMS ordentlich lief. Gut, es hatte auch was mit dem KnowHow der Leute zu tun. Aber die dazu benötigte Erfahrung kommt auch nicht von allein.

Bis denn,
Thomas