Komponenten zum Zugriff auf Datenbank...

[ralfiii]

Hallo!

Ich mache gerade einen Rewrite einer groesseren Anwendung die sich unter anderem auch mit einer Datenbank verbindet.
Momentan ist das Firebird via IBX.
Wir wurden aber auch schon einige male gefragt ob wir auch mysql oder MS-SQL unterstützen könnten.

Ich hab schon ein paar mal was von DBExpress gehört, wobei ich's noch nie selbst probiert hab.

Nun wollte ich mir das heut mal schnell anschauen und hab festgestellt, dass die Beispiele die mit Delphi 2010 mitkommen
*) fehlerhaft sind (DB-Pfad fix kodiert auf C:\program files\,, gesetzt)
*) IBExpress zum DB-Zugriff verwenden.

Ich hab genau garnix zum Thema DBExpress entdeckt.

Was wäre denn momentan Wahl der Waffen wenn man einen flexiblen Datenbank-Zugriff realisieren will?
Oder soll ich bei IBX bleiben und hoffen, dass wir die DB nie wechseln?

Danke,
Ralf

[mkinzler]

-Unidac
-AnyDac

[RWarnecke]

Um einen variablen Datenbankzugriff zu realiseren würde ich auf zwei Komponenten zurückgreifen :

Zeos (Kostenlos)
UniDAC (Kostenpflichtig)

[tsteinmaurer]

Das mit der Unterstützung mehrerer Datenbanken ist eine eigene Wissenschaft. Wenn es geht, würde ich das immer vermeiden!

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. Obwohl das Ganze zu Beginn vielleicht einfach erscheint, werden Dinge schnell mal komplex. Es muss dann auch noch für jede DBMS getestet werden. Naja, hängt halt auch vom Umfang der Anwendung ab. Ein Mickey-Mouse Programm kann mit AnyDAC, UniDAC ... für unterschiedliche DBMS schnell mal realisiert werden.

[Bernhard Geyer]

Zitat:

Zitat von tsteinmaurer (Beitrag 1087860)

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:

Zitat von tsteinmaurer (Beitrag 1087860)

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:

Zitat von tsteinmaurer (Beitrag 1087860)

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

[ralfiii]

Zitat:

Zeos (Kostenlos)
UniDAC (Kostenpflichtig)
-AnyDac

Und was ist von den Delphi-Boardmitteln zu halten?
Ist DBExpress noch - laut Emba - das Mass der Dinge oder gibt's da schon wieder was neueres?

[mkinzler]

dbExpress ist sehr eigen und eigentlich nur ab der Enterprise richtig nutzbar ( pro erlaubt nur 5 lokale Verbindungen)

[ralfiii]

Zitat:

Zitat von mkinzler (Beitrag 1088308)

dbExpress ist sehr eigen und eigentlich nur ab der Enterprise richtig nutzbar (pro erlaubt nur 5 lokale Verbindungen)

eeeh... Wie?
Mie meinst du "5 lokale Verbindungen"?
5 offene Queries/Tables? Oder können pro Rechner maximal 5 Clients (Exes) zugleich via DBExpress irgendwo hin verbinden? Oder pro Rechner max. 5 Verbindungen auf einen bestimmten Server? Oder ganz anders?


Ich hab mal in der Delphi Feature Matrix nachgesehen, da steht
"dbExpress Server connectivity to Firebird 1.5 and 2.1" - hat man nur bei Architect und Enterprise.

Mal ganz blöd: Ich versteh den Satz nicht. Was ist der dbExpress Server?
Oder heisst das, dass ein mit Delphi2010Pro geschriebener Client gar nicht an Firebird rankommt?

Fragen über Fragen...

[mkinzler]

5 lokale Verbindungen, bedeuted 5 Verbindungen ( an jeder können mehrere Zugriffskompos wie Query, Table, DataSet hängen) auf einen lokal installierten DB-Server