dbExpress - Vor- und Nachteile

[merlin17]

Hallo,

wie sind eigentlich die Erfahrungen mit dbExpress unter dem Aspekt

- connect mit unterschiedlichen Datenbanken

und

- unterstützung von VCL und VCL.net

Es geht um ein Projekt (welches schon gestartet ist, k.A. wie lange schon daran entwickelt wird) dass
auf dbExpress vollständig aufbaut (aufbauen soll). Von der Fa. werden die obigen Punkte als die optimale
Lösung genannt.

Ich arbeite bisher immer mit Oracle über native Komponenten (DOA) und mit InterBase mit IBX bzw. FIBPlus, d.h.
nicht generelle Komponenten; daher fehlen mit Erfahrungen mit dieser generic-schnittstelle von Borland;
"spielanwendungen" habe ich damit schon erstellt, aber noch nichts "mission-criticals".


Danke für alle Meinungen!


thomas

[Bernhard Geyer]

Auch bei dbExpress könnte man wenn man sich halbwegs aktuelle und gut implementierte DLL's herunterläd/kauft auch gut Implementieren (Die von Borland mitgelieferten Treiber haben schon fast antiken Status: MySQL immer noch nur auf 4.0er-Stand bei Delphi 2006 und damit praktisch nicht mehr zu verwenden da die neue Passwortverschlüsslung die mit MySQL 4.1 eingführt wurde nicht unterstützt wird).

Auch soll (EKON 10-Info) in der nächsten Delphi-Version die BDP und dbExpress-Schiene auf gleiche Treiber aufsetzen (Ist ja auch Blödsinn das Borland für jedes DBMS 2 Treiber pflegen muss). Jedoch lößt weder BDP noch dbExpress das eigentliche Problem der SQL-Unterschiede. Das wird erst mit ECO oder anderen Objektframeworks wie N/Hypernate gelößt. Selbst haben wird den Schritt (glücklicherweise) nach dbExpress nicht gemacht sondern sind auf TDataset-Basis geblieben, haben die DB-Zugriffsschicht mittels Bridge-Pattern gekapselt und arbeiten intern mit eigenen (disconnected) Dataset-Klassen. Für den Zugriff auf MS SQL-Server verwenden wir mittlerweile nur noch die nativen ADO-Komponenten und kein ADOExpress/dbGo.

Also: DB-Schnittstelle kapseln, keine DB-Sensitiven Controls einsetzen und dann ist es auf DB-Zugriffschicht schon wieder egal ob du dbExpress oder TDataset oder ADO nimmst.

[OMLune]

Hi, wir nutzen seit Delphi 8 auch dbExpress als Ersatz für die BDE. Leider mussten wir bei der Umstellung auf Delphi 2006 feststellen, dass dbExpress unter .Net sehr langsam ist. Jeder Zugrif auf ein Feldinhalt eines Queries ist ein mehrfacher Aufruf von unmanaged Code, erzeugt also sehr viel Overhead.

Wir haben dann mal versucht die gleichen Daten über ADO.Net einzulesen, das Ergebnis war erschreckend. Bei unseren Datenmangen lagen wird bei dbExpess=4 Minuten ADO.net=40 Sekunden

Der Vorteil von dbExpress ist natürlich, dass man den Code sehr einfach in Win32 und .Net nutzen kann.

Da wir aber auf .Net umgestellt haben und auch da bleiben wollen, werden wir wohl auch komplett auf ADO.Net wchseln.

[Elvis]

Zitat von OMLune:

Da wir aber auf .Net umgestellt haben und auch da bleiben wollen, werden wir wohl auch komplett auf ADO.Net wchseln.

Wie ich dir in b.p.d.data.dbexpress empfohlen habe, schaue dir mal den ODP von Oracle an.

@Thomas
Für einen eingessenen DOA user ist .Net erstmal etwas entäuschend für den Oracle Fritzen.
Es gibt praktisch keinen Support für Ora-Objekte und auch der ODP reicht um Längen nicht an die Performance von TOracleQuery ( ) heran. Der ODP ist aber oftmals trotzdem schneller als es Zugriffe über native ADO waren.
dbX ist davon nochmal ein Vielfaches langsamer (siehe mein Vorredner ).

edit: Der .Net-Port von dbX ist ziemlich lahm, aber auch native war es nicht wirklich flink. (Verglichen mit DOA sogar lächerlich)