Umstieg MySQL auf MS SQL Server

[Lemmy]

Hallo,

ich kann zu MS SQL nichts beitragen, möchte aber meine Erfahrung zum Thema ADO - ODBC - MySQL hier einbringen:

Ich habe eine Anwendung von ADO - ODBC - MySQL auf Devart (MyDAC) umgestellt und damit eine ca. 15% Performancesteigerung erreicht - bei einzelnen SQL-Abfragen lag die Steigerung im Spitzenwert bei gut 30-40%

Daher würde ich die ADO - ODBC - Irgendwas Bridge als Notlösung akzeptieren, aber nicht als was dauerhaftes. Davon abgesehen dass zumindest bei MySQL 5.1 die ODBC Treiber auch so ihre Tücken haben....

[Bbommel]

Zitat von Lemmy:

Ich habe eine Anwendung von ADO - ODBC - MySQL auf Devart (MyDAC) umgestellt und damit eine ca. 15% Performancesteigerung erreicht - bei einzelnen SQL-Abfragen lag die Steigerung im Spitzenwert bei gut 30-40%

Daher würde ich die ADO - ODBC - Irgendwas Bridge als Notlösung akzeptieren, aber nicht als was dauerhaftes. Davon abgesehen dass zumindest bei MySQL 5.1 die ODBC Treiber auch so ihre Tücken haben....

Für MySQL mag das tatsächlich ein Problem sein. Als ich das früher mal benutzt habe, war ich davon auch nicht rundum begeistert. Microsoft selbst sieht in einer FAQ zur SQL Server-Anbindung (https://msdn.microsoft.com/en-us/sql.../aa937707.aspx) keine Probleme und eigentlich auch kaum einen Unterschied zwischen ODBC und OLE DB.

MS sagt recht selbstbewusst:

Zitat:

Q. ODBC is a "wrapper" API and is inherently inefficient, right?

A. This may be true for some ODBC drivers, but not for SQL Server Native Client. ODBC in SQL Server Native Client and also in MDAC is a true native API for SQL Server.

Naja, müsste man mal testen. Auf jeden Fall läuft bei mir ADO->OLE DB->MS SQL sehr performant (und die Probleme, die ich mal hatte, waren alle von mir selbst verursacht - falsche Cursor-Location und so - und hier in der DP wurden die immer gelöst).

[teebee]

Vielen Dank für die Hinweise, ich denke ich werde es mit den ADO-Komponenten machen, habe ich ja an Bord. Erste Versuche waren ganz vielversprechend.
Trotzdem irgendjemand hier, der für MSSQL ZEOS benutzt, bzw. aus bestimmten Gründen nicht?

[jobo]

Zitat von teebee:

Trotzdem irgendjemand hier, der für MSSQL ZEOS benutzt, bzw. aus bestimmten Gründen nicht?

Mal sehen, wer antwortet. Ich gehöre nicht dazu, spielt aber hier keine Rolle.
Mein Tipp wäre, das macht selten jemand, weil die Komponenten eben im Open Source bereich angesiedelt sind.

[Perlsau]

Zitat von teebee:

Trotzdem irgendjemand hier, der für MSSQL ZEOS benutzt, bzw. aus bestimmten Gründen nicht?

Vor vielen Jahren hatte ich mal Zeos im Einsatz, damals waren diese DB-Komponenten noch unidirektional, keine Ahnung, ob das immer noch so ist. Wenn du herausfinden willst, ob Zeos auf irgend eine Weise dbGo überlegen ist, mach doch einfach mal ein paar Tests mit einer Testanwendung und einer Test-Datenbank. Ich verlasse mich nur selten auf die Aussagen anderer, wenn ich die Möglichkeit habe, selbst zu untersuchen und zu vergleichen.

Die Komponenten von DevArt kann ich ebenfalls empfehlen. Ich hab mir für Firebird die Basic-Variante von IbDac besorgt, die ist ohne Quellcode und kostet damals wie heute 100 US-Dollar. Für dich wäre dann wohl SDac die entsprechende Komponentensammlung.

... und nein, ich erhalte keine Provision, sondern empfehle das nur deshalb weiter, weil ich die Devart-Komponenten für die besten am Markt halte ... selbstverständlich neben FireDac, das aber für Benutzer älterer Delphi-Versionen nicht zur Verfügung steht.

[mkinzler]

Oder UniDAC, da dann sowohl MSSQL wie auch MySQL unterstützt wird.

[Perlsau]

Zitat von mkinzler:

Oder UniDAC, da dann sowohl MSSQL wie auch MySQL unterstützt wird.

Stimmt, wenn man häufig mit unterschiedlichen DBMS arbeitet. Bei MsSQL und MySQL nehme ich noch immer dbGo, das reicht für mich, weil's da sowieso nur um private Projekte geht.

Muß man bei UniDAC nicht zusätzlich die Provider-Dateien erwerben? Ich erinnere mich nämlich noch daran, daß ich zuerst versehentlich bzw. aus Unkenntnis die Basic-Version der Unidac-Komponenten erworben hatte und danach feststellen mußte, daß ich damit gar nichts anfangen kann, weil die entsprechenden Provider fehlten. Hier im Forum gab man mir dann den Rat, ich solle versuchen, die umzutauschen, was DevArt auch anstandslos ohne Zusatzkosten gemacht hat, nachdem ich mein Dilemma erklärt hatte. Oder sind die Provider bei den Pro-Versionen alle dabei? Naja, egal, ich werde sie ja sowieso nicht erwerben.

[mkinzler]

Ja, bei der Pro sind die Provider dabei. Diesen müssten auch schon bei der Standard dabei sein:

https://www.devart.com/unidac/editions.html

Ich würde die Version mit Sourcen wählen.

[Bernhard Geyer]

Zitat von Perlsau:

Zitat von mkinzler:

Oder UniDAC, da dann sowohl MSSQL wie auch MySQL unterstützt wird.

Stimmt, wenn man häufig mit unterschiedlichen DBMS arbeitet. Bei MsSQL und MySQL nehme ich noch immer dbGo, das reicht für mich, weil's da sowieso nur um private Projekte geht.

Privat ist das keine Problem, aber bei Kommerzieller SW wärst du mit dbGO/ADO und MySQL in der GPL-Falle.

[p80286]

Zitat von teebee:

Vielen Dank für die Hinweise, ich denke ich werde es mit den ADO-Komponenten machen, habe ich ja an Bord. Erste Versuche waren ganz vielversprechend.
Trotzdem irgendjemand hier, der für MSSQL ZEOS benutzt, bzw. aus bestimmten Gründen nicht?

Ich hab vor einiger Zeit ZEOS mal ausprobiert, war aber nicht unbedingt begeistert bzw. hab' ich keinen Vorteil gegenüber ADO/dbGo gesehen.


Gruß
K-H