BDE Umstieg auf welche Datenbank?

[MasterDetail]

Hallo,

wir sind dabei unser Projekt von der BDE zu trennen.
Nun sind wir uns noch nicht sicher, welches DBMS und welche Komponenten wir in Betracht ziehen.

Wir hatten uns vorerst dazu entschlossen, es mit MySQL/InnoDB und FireDAC zu probieren. Bisher lief das auch ganz gut.
Jedoch hatten wir Probleme mit den Indizes, die bisher auf der Datenbank global hinterlegt waren, doch nun bei den FDQuerys einzeln angelegt werden müssen.
Das erschwert die Übersicht. Wir hatten uns für FDQuerys entscheiden, damit wir Lookup- und CalcFields in die SELECT-Anweisung packen und somit an Performance gewinnen.

Des Weiteren ist uns ein weiteres Problem mit großen Datenmengen aufgefallen. Hierfür soll man ja RowSetSize und fmOnDemand benutzen.
Sobald man eine zweite FDQuery öffnet, wird jedoch bei der ersten FDQuery (RowSetSize:=50,Mode:=fmOnDemand) in jedem Fall ein FetchAll ausgeführt.
Das Problem ist hier näher beschrieben.

Sollten wir vielleicht doch andere Komponenten benutzen?

Welche Datenbank würdet ihr empfehlen? Und da einige von euch die BDE bereits verlassen haben, welche Datenbank wird von euch verwendet?

Außerdem habe ich von einem Lizenzproblem mit MySQL gelesen. Hat jemand von euch damit schon Erfahrung gesammelt?

Vielen Dank.

[haentschman]

Moin...:P

Als (einzige :thumb:) Alternative ist imho Firebird. Ein Datenbank File welches sowohl Embedded als auch mit Server läuft. :thumb: Zu FireDAC kann ich nicht viel sagen. (positiv / negativ) :?

Da ich nicht viel über eurer Projekt weiß...

Tipps:
1. Eine Umstellung 1:1 wird nicht funktionieren.
2. Die Datenbanken haben alle ihre Eigenheiten.
3. Lohnt sich der Einsatz eines Frameworks? (Aurelius z.b.) = Umsetzung der Datenmenge auf (generische) Listen.
4. Die SQL sollten wenigstens in einem Interface gekapselt werden. (Austauschbarkeit DBMS) = Umsetzung der Datenmenge auf (generische) Listen.
5. Evt. können die SQL als Ressource abgelegt werden. (Testbarkeit außerhalb vom Quelltext)
6. WICHTIG: Wenn möglich auf serverseitigen Cursor verzichten.
7. Trennung von datensensitiven Controls... :wink:

[nahpets]

Über welche Datenmengen reden wir da?

Für kleine Datenmengen (ein paar hundert Sätze) nutze ich für dBase einfach TDBF.

Ansonsten je nach Bedarf.

Kleinere Datenmengen mit Access über ADO.

ADO nutze ich auch dann, wenn ich nicht weiß, welche Datenbank letztlich vom Programm genutzt werden soll.
Kann halt dann alles, an das man über ODBC ... "rankommt".

FireBird scheint mir eine gut nutzbare Datenbank zu sein, egal ob mit Datenbankserver und Client oder die Embeddedversion.

Bei großen Datenbanken (mit eigenem Datenbankserver) Oracle oder SQL-Server.

Ab und an nutze ich als Zugriffkomponenten auch mal die ZeosLib.

Allerdings kenne ich mich mit den neueren Delphiversionen und ihren Komponenten nicht aus. Bin (inzwischen nur noch Hobbyprogrammierer) bei Delphi 7 "stehen geblieben".

[Bernhard Geyer]

Zitat:

Zitat von MasterDetail (Beitrag 1347500)

Jedoch hatten wir Probleme mit den Indizes, die bisher auf der Datenbank global hinterlegt waren, doch nun bei den FDQuerys einzeln angelegt werden müssen.

Ist das wirklich notwendig oder nur ein "Hinweis" an die Controls das es hier Indexe gibt die verwendbar sind.

Zitat:

Zitat von MasterDetail (Beitrag 1347500)

Des Weiteren ist uns ein weiteres Problem mit großen Datenmengen aufgefallen. Hierfür soll man ja RowSetSize und fmOnDemand benutzen.
Sobald man eine zweite FDQuery öffnet, wird jedoch bei der ersten FDQuery (RowSetSize:=50,Mode:=fmOnDemand) in jedem Fall ein FetchAll ausgeführt.
Das Problem ist hier näher beschrieben.

Das liegt wie geschrieben an MySQL. Es ist auch sinnvoll sich vom Serverseitgen Curser zu lösen und nur Clientseitige DBs zu verwenden und Datenmengen wenn nötig/sinnvoll auf Sinnvolle Datenmengen zu beschränken. Du kannst zwar "einfach" mit Serverseiten Cursern Mio.-Datensätze "bearbeiten" (im Grid halten), aber hier hat dann das DBMS einige zu werkeln diese Datenmengen auf dem Server vorzuhalten. Stell dir vor dein Programm nutzen 1000 User um jeweils 100 Mio. Datensätze im Grid darzustellen. Da dürftest du dann schon ein ziemliches Performance-Problem bekommen.

Zitat:

Zitat von MasterDetail (Beitrag 1347500)

Welche Datenbank würdet ihr empfehlen? Und da einige von euch die BDE bereits verlassen haben, welche Datenbank wird von euch verwendet?

Am besten das was der Kunde schon im Einsatz hat. Damit seit ihr aus der Nummer DB-Administration und Backupkonzept mehr oder minder raus als wenn ihr einem Kunden der MS-SQL-Server im Einsatz hat sagen müsst das er jetzt auch noch ein Oracle/MySQL/... installieren und administrieren muss.

Zitat:

Zitat von MasterDetail (Beitrag 1347500)

Außerdem habe ich von einem Lizenzproblem mit MySQL gelesen. Hat jemand von euch damit schon Erfahrung gesammelt?

Sollt ihr nur MySQL und/oder die libmysql.dll im Einsatz haben, so muss der Kunde die Installation lizensieren.
Nur wenn ihr mehrer DBMS unterstützt und auch keine DLL von MySQL im Einsatz habt seit ihr außen vor.

[jaenicke]

Wir nutzen ebenfalls von der BDE kommend MS-SQL, MySQL und MariaDB ebenfalls in Kombination mit FireDAC. MariaDB hat den Vorteil, dass du das Lizenzproblem von MySQL nicht hast.

Damit MariaDB mit FireDAC funktioniert, musst du lediglich die Konstante mvMySQL060200 aus FireDAC.Stan.Consts auf einen höheren Wert als die von MariaDB verwendete Versionsnummer setzen (z.B. 2000000000) und MySQL als Treiber nutzen. Das Überschreiben der Konstante funktioniert z.B. schlicht mit VirtualProtect usw. im Speicher.

[bcvs]

Zitat:

Zitat von MasterDetail (Beitrag 1347500)

Und da einige von euch die BDE bereits verlassen haben, welche Datenbank wird von euch verwendet?

Das ist bei mir schon etwas länger her (ca. 10 Jahre). Ich bin bei den Produkten von www.elevatesoft.com gelandet. Zuerst DBISAM, dann ElevateDB.

[Lemmy]

Hallo,

ich würde FireDac nur dann in Betracht ziehen, wenn ihr eine SA habt, damit ihr bei ggf. auftretenden Fehlern nicht erst teuer investieren müssen. Als Alternative würden die Komponenten von DevArt in Betracht kommen, dort werden auch ältere Delphiversionen mit Updates versorgt.


Je nach Einsatzzweck und Kundentyp kann durchaus sein, dass der Kunde die Datenbank "vorschreibt" - da wäre dann ein ORM (was den Umstieg teurer macht) oder zumindest eine universelle DAC (wie Firedac oder UniDac) notwendig um unterschiedliche Systeme unterstützen zu können.


Zur Lizenzproblematik von MySQL wurde schon was gesagt, ich würde einen Bogen drum machen (auch aus anderen Gründen).

Aktuell würde ich Firebird und PostGreSQL empfehlen. Beide kostenfrei, beide aktiv entwickelt.

[MasterDetail]

Zitat:

Zitat von jaenicke (Beitrag 1347508)

Wir nutzen ebenfalls von der BDE kommend MS-SQL, MySQL und MariaDB ebenfalls in Kombination mit FireDAC. MariaDB hat den Vorteil, dass du das Lizenzproblem von MySQL nicht hast.

Damit MariaDB mit FireDAC funktioniert, musst du lediglich die Konstante mvMySQL060200 aus FireDAC.Stan.Consts auf einen höheren Wert als die von MariaDB verwendete Versionsnummer setzen (z.B. 2000000000) und MySQL als Treiber nutzen. Das Überschreiben der Konstante funktioniert z.B. schlicht mit VirtualProtect usw. im Speicher.

Wie meinst du das? Wir haben nämlich das ganze mit XAMPP und InnoDB-Tabellen getestet und den MySQL Dienst gestartet. Wie habt ihr das gemacht? Kannst du das genauer erläutern?

[FBrust]

Hallo,

ich bin damals von der BDE zu Firebird, zuerst mit ZEOS, mittlerweile mit IBDAC (von Devart), habs nie bereut. PostgreSQL ist ebenfalls empfehlenswert.

Gruß
Frank

[franktron]

Also wir haben auch von BDE nach MySQL migriert und das mit UNIDAC läuft alles schön und schnell