Mit welcher Komponente mit Firebird DB verbinden?

[Lemmy]

Hi,

Zitat von DataCool:

Sollte ich bei der Geschwindigkeitsaussage falsch liegen, werde ich mir für mein nächstes Projekt wohl dann noch IBDac kaufen ...,
aber das werde ich bei Gelegenheit mal in Ruhe mit der Trial Version austesten.

ich habe hier gerade ein Projekt ADO + ODBC auf MySQL. Unterschied zu MyDac (MySQL direkt) beträgt Faktor 2-2,5. Da lohnt sich der Umbau - wobei der sich zum GLück auf eine einzige Unit beschränkt .
Ich vermute der Unterschied von UniDac zu IBDac dürfte marginal sein. Viel wichtiger ist hier die Unterstützung von DB-spezifischen Features um die DB auszureizen.

Und woher die MultiDB-Unterstützung kommt? Sollte doch klar sein, wenn man eine RAD-IDE hat (Stichwort Klicki-Bunti "... und außerdem können wir mit 15 Datenbanksystemen...."). Funktioniert irgendwie, aber bei keiner DB so richtig.

[Perlsau]

Zitat von Lemmy:

Und woher die MultiDB-Unterstützung kommt? Sollte doch klar sein, wenn man eine RAD-IDE hat (Stichwort Klicki-Bunti "... und außerdem können wir mit 15 Datenbanksystemen....").

Seh ich ähnlich: man kann entweder viel verschiedenes nur halb oder ein paar wenige Dinge sehr gut. Der Tag hat auch für Multifunktionsthreaduser und eierlegende Wollmilchsäue nur 24 Stunden ...

Zitat von Lemmy:

Funktioniert irgendwie, aber bei keiner DB so richtig.

Ist mir auch schon aufgefallen, deshalb hab ich ja jetzt IbDac ...

[Hansa]

Zitat von Lemmy:

... Viel wichtiger ist hier die Unterstützung von DB-spezifischen Features um die DB auszureizen.

Und woher die MultiDB-Unterstützung kommt? Sollte doch klar sein, wenn man eine RAD-IDE hat (Stichwort Klicki-Bunti "... und außerdem können wir mit 15 Datenbanksystemen...."). Funktioniert irgendwie, aber bei keiner DB so richtig.

Das da widerspricht sich aber doch gewaltig. Ausreizen und kleinster geneinsamer Nenner ? Wie das ?

[Perlsau]

Zitat von Hansa:

Zitat von Lemmy:

... Viel wichtiger ist hier die Unterstützung von DB-spezifischen Features um die DB auszureizen.

Und woher die MultiDB-Unterstützung kommt? Sollte doch klar sein, wenn man eine RAD-IDE hat (Stichwort Klicki-Bunti "... und außerdem können wir mit 15 Datenbanksystemen...."). Funktioniert irgendwie, aber bei keiner DB so richtig.

Das da widerspricht sich aber doch gewaltig. Ausreizen und kleinster geneinsamer Nenner ? Wie das ?

Verstehe ich nicht: Du selbst hattest doch in Posting Nr. 22 geschrieben: "Jedem normalen Programmierer müsste doch wohl klar sein, dass wie im normalen Leben der kleinste gemeinsame Nenner nie und nimmer ein Optimum darstellen kann."

Was sollte sich da widersprechen? Und auch noch "gewaltig"? Ich jedenfalls kann Lemmy's Ausführungen nicht nur nachvollziehen, sondern ihnen auch zustimmen: Wenn man sich hauptsächlich mit einem DBMS befaßt, lernt man dieses besser kennen als wenn sich man ständig mit verschiedenen DBMS auseinandersetzen muß. Seine Parodie der Reklame für eine bestimmte IDE bringt es auf den Punkt: Was nützt es, wenn mitgelieferte DB-Komponenten zwar irgendwie Kontakt zu zahlreichen DBMS anpreisen, in der Praxis aber unter Fehlern und Performance-Einbrüchen leiden?

[Hansa]

Zitat von Perlsau:

Seine Parodie der Reklame für eine bestimmte IDE bringt es auf den Punkt: Was nützt es, wenn mitgelieferte DB-Komponenten zwar irgendwie Kontakt zu zahlreichen DBMS anpreisen, in der Praxis aber unter Fehlern und Performance-Einbrüchen leiden?

Aber es stimmt, ich habe Lemmies Ironie unterschätzt. Unter dem Aspekt gesehen sind wir einer Meinung.

[mkinzler]

Wobei der Einsatz von Multidatenbank-Komponenten per se nicht unperformant sein muss. UniDAC und FireDAC implementieren auch nicht nur den gemeinsamen Nenner.

[Furtbichler]

Ich glaube, hier werden zwei Use Cases miteinander vermengt:

1. Implementierung einer konkreten Anwendung. Hier ist es für 99% der Anwender sinnvoller, sich auf eine DB einzuschießen. Die individuelle Implementierung irgendwelcher Speziallösungen kann vielleicht für eine bestimmte DB gar nicht oder nur mit Klimmzügen suboptimal möglich sein. Paradebeispiel 'bulk updates' (eigentlich ein ETL-Prozess). Geht mal so, mal so und mal gar nicht (performant). Da kommt man um individuelle Lösungen gar nicht drum herum und muss die unterstützten DB einschränken oder für eine bestimmte DB eine Schrottlösung anbieten.

2. Implementierung eines Dataaccess-Layers. Hier werden 'einfach' die unterschiedlichen DB-Protokolle vereinheitlicht. Eine performante Umsetzung ist hier viel einfacher, denn es müssen nur Basistechnologien (Konnektieren, Befehle abschicken, Daten Empfangen, Fehlerbehandlung) unter einen Hut gebracht werden. bulk updates gehören imho bisher jedenfalls nicht dazu (aus genannten Gründen).