cross-database support: performance vs. dev effort
Posted: Thu 30 Apr 2009 23:47
These aren't really UniDirect questions per se, but it's related, so this seems to be the best forum. I have a ton of cross-database platform related questions...
I'm building a quite large enterprise product (in C#) that will require using a customer provided provided database license on 3 databases (potentially 3 different servers), and need to support:
Oracle
SQL Server
MySQL
Postgres
DB2
I want to build my database layer to be as portable as possible to reduce development effort and maintenance costs. However, this time savings can not trump performance. One of the datastores in particular needs absolutely best possible performance.
I'm leaning against UniDirect for several reasons:
- there appears to be no version that supports latest dotConnect providers
- there appears to be no new version recently at all (11 months)
- there are a lot of posts complaining about performance
From a performance standpoint, is it indeed true that I would be better off using the various dotConnect providers as well?
Is it true that in order to maximize cross-platform portability, I'll be best off avoiding any "customizations" in the pro versions of the various dotConnect products, and in fact if I stick with core System.Data base abstract classes and interfaces, things will in general be much more portable?
Is there a performance difference between dotConnect for SQL Server and dotConnect for Oracle vs. what MS provides natively in the .Net Framework, for the *standard* features? If so which performs better, and under what scenarios?
Using the EF is going to clearly save me time, and I believe it will also increase portability. However, I am concerned about the performance overhead. Can anybody share their experiences here? It may be that for a few of our data stores for fringe functionality we use EF, but for the core datastore that has to scream we use ADO.net providers directly.
I'm still not 100% sold that ODBC wouldn't be my best route. For each of the database vendors listed above, is it indeed true that going with the dotConnect provider will always provide superior performance over using the System.Data.Odbc and just relying on the underlying vendor-provided Odbc diver? Most ADO.Net articles I've read show that it is usually faster than ODBC, but these invariably compare SQL Server only. They also use the "stock" ODBC drivers, and not wire-protocol drivers from 3rd party vendors which have significantly better performance and scalability.
Why is there no DB2 dotConnect product? Am I missing something?!?
Finally, are any/all dotConnect provider implementations "wire protocol" implementations, or do they go throught he client libraries provided by the particular database vendor?
Thanks in advance for answering these questions...
- Rhino
I'm building a quite large enterprise product (in C#) that will require using a customer provided provided database license on 3 databases (potentially 3 different servers), and need to support:
Oracle
SQL Server
MySQL
Postgres
DB2
I want to build my database layer to be as portable as possible to reduce development effort and maintenance costs. However, this time savings can not trump performance. One of the datastores in particular needs absolutely best possible performance.
I'm leaning against UniDirect for several reasons:
- there appears to be no version that supports latest dotConnect providers
- there appears to be no new version recently at all (11 months)
- there are a lot of posts complaining about performance
From a performance standpoint, is it indeed true that I would be better off using the various dotConnect providers as well?
Is it true that in order to maximize cross-platform portability, I'll be best off avoiding any "customizations" in the pro versions of the various dotConnect products, and in fact if I stick with core System.Data base abstract classes and interfaces, things will in general be much more portable?
Is there a performance difference between dotConnect for SQL Server and dotConnect for Oracle vs. what MS provides natively in the .Net Framework, for the *standard* features? If so which performs better, and under what scenarios?
Using the EF is going to clearly save me time, and I believe it will also increase portability. However, I am concerned about the performance overhead. Can anybody share their experiences here? It may be that for a few of our data stores for fringe functionality we use EF, but for the core datastore that has to scream we use ADO.net providers directly.
I'm still not 100% sold that ODBC wouldn't be my best route. For each of the database vendors listed above, is it indeed true that going with the dotConnect provider will always provide superior performance over using the System.Data.Odbc and just relying on the underlying vendor-provided Odbc diver? Most ADO.Net articles I've read show that it is usually faster than ODBC, but these invariably compare SQL Server only. They also use the "stock" ODBC drivers, and not wire-protocol drivers from 3rd party vendors which have significantly better performance and scalability.
Why is there no DB2 dotConnect product? Am I missing something?!?
Finally, are any/all dotConnect provider implementations "wire protocol" implementations, or do they go throught he client libraries provided by the particular database vendor?
Thanks in advance for answering these questions...
- Rhino