Hi,
Ihr habt alle recht, wenn Ihr wie z.B. Hansa sagt "Support für mehrere DBs gleichzeitig, kann nie das Optimum sein"
das unterschreibe ich auch sofort zu 100% .
Genauso habt Ihr Recht das man sich am besten vor Projektstart auf eine
DB festlegt
und dann für diese
DB direkt entwickelt.
Mache ich bei meinen Projekten eigentlich auch immer so.
Entwickelt man allerdings Standard-Software oder eine Software die irgendwann "Standard-Software" werden soll
sieht das ganze in meinen Augen etwas anders aus.
Bsp.:
Ein früherer Arbeitgeber von mir hat Software-Produkte im Pflegebereich entwickelt,
Zielgruppe ist breit gefächert vom kleinen Pflegedienst bis hin zur großen Uni-Klinik.
Der kleine Pflegedienst war/ist froh mit Firebird keine extra Lizenz Kosten für die Datenbank zu haben.
Bei den Uni-Kliniken hingegen ist zu 95% schon einen "riesen"
DB-Server im Haus vorhanden(
MsSQL oder Oracle)
und die Kauf-Entscheider fragen gezielt nach ob das schon vorhandene
DB-System unterstützt wird.
Keine Unterstützung des vorhandenen
DB-Systems = Produkt ist direkt aus dem Rennen.
.....
Wenn ich mir jetzt IBDAC und UniDAC(beide von DevArt) anschaue, Komponenten vergleiche ....
Dann wage ich mal die Vermutung zu äußern das UniDac einfach einen Abstrakten Wrapper auf Ihre einzelnen Produkte(ODAC, SDAC, MyDAC, IBDAC, PgDAC, LiteDAC)
liefert und somit der Zugriff selber wahrscheinlich sogar die selbe Codebasis hat, deshalb sollte es in meinen Augen keinen großen
Geschwindigkeitsunterschied geben und die Verwendung von UniDac nur eine zusätzliche Option bieten die
DB zu wechseln,
WENN man es aus irgendwelchen Gründen muss.
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.
Greeetz Data
Der Horizont vieler Menschen ist ein Kreis mit Radius Null, und das nennen sie ihren Standpunkt.