I'm looking for suggestions as well as any benchmarks or observations people have. We are looking to rewrite our data access layer and are trying to decide between native C++ OLEDB or ADO.NET for connecting with databases. Currently we are specifically targeting Oracle which would mean we would use the Oracle OLE DB provider and the ODP.NET.
Requirements:
1. All applications will be in managed code so using native C++ OLEDB would require C++/CLI to work (no PInvoke way to slow).
2. Application must work with multiple databases in the future, currently just targeting Oracle specifically.
Question:
1. Would it be more performant to use ADO.NET to accomplish this or use native C++ OLE DB wrapped in a Managed C++ interface for managed code to access?
Any ideas, or help or places to look on the web would be greatly appreciated.
I don’t think it is possible to give a single answer that is generally applicable in this situation considering the fact that you are wanting a general solution for more than just Oracle. The problem is that one vendor’s .NET provider might be faster than their OLE DB provider and vice versa for another vendor. The architecture of both of those data access technologies is significantly different.
My gut feel is that the speed differences would not be that great, though. Since it sounds like you would put your own data access layer on top of OLE DB, it is hard compare directly until you wrote that. But in general, any data modification statement (e.g., UPDATE mytable set…) probably is not going to be all that different in either case. With both technologies, you specify parameter data if appropriate and then send the command to the server. The bulk of the cost is likely going to be network latency and server execution times. The biggest difference would probably come into play when reading data sets.
Reading the data is going to be the factor that could show a difference in speed. Depending on what you are planning, you may want to read the data at a low level. For example, with OLE DB, you may call IRowset::GetNextRows. With .NET, you would maybe read through the data sets via DbDataReader::Read(). I don’t know if it is typical, but in the code I worked on, the OLE DB GetNextRows() method was much more complex than the .NET Read() implementation. I am not sure if that necessarily translates to slower execution … but it might.
In my opinion, the best choice would be to use ADO.NET. Since it is Microsoft's current data access technology, I suspect that vendors will update their .NET provider more often than their OLE DB provider. So if there are performance problems in implementation, the .NET provider is likely going to be fixed while their OLE DB provider may not be fixed as promptly (or at all). Also, you get a lot more flexibility with the .NET provider if you need it (e.g., entity framework). If you want that with OLE DB, you are going to need to use the .NET provider for OLE DB providers, which is another layer on top of OLE DB (assuming it would even work, which I do not know).
Related
I will have a Postgres database in production but want to use MS SQL (whatever edition) for reporting. So, I would like to have replication set up where MS SQL subscribes from postgres. Is this possible?
All heterogeneous replication scenarios are deprecated by Microsoft, and they now recommend building solutions using SSIS and CDC instead.
We load data from PostgreSQL into our SQL Server reporting database using SSIS and it works well, although we had to use a commercial OLE DB provider because of limitations (at that time) in the open-source one.
Actually copying the data is usually the easy part; most of the work comes in gathering requirements, understanding the data, transforming it, implementing logging and error handling etc. SSIS can do some things for you right away (e.g. logging) but my general advice would be to use it primarily as a workflow tool and for simple data copying with minimal transformation logic (e.g. data type conversion). If something seems seems too difficult or clumsy in SSIS then you can put it into a stored procedure or script and call that from SSIS instead.
I've been using and following PostgreSQL for several years and not aware of such a solution. If one exists, I'm concerned that might be complex or fragile. I would recommend regular export/imports via cron. In the between the export and import, you would need to take care of the translation step of the formats.
If you reporting actually happens in MS Excel or MS Access, I recommend looking into connecting them directly to PostgreSQL via ODBC.
I don't know between ADO, DAO and DLookUps and such. Does anyone know?
I find that the application bottleneck is usually the actual SELECT/INSERT/UPDATE on the DB and not how the application calls it. if you are worrying about speed make sure you have well designed tables and indexes.
Regarding DAO vs ADO, I'm not sure about a difference in performance but there is a difference in available functionality.
There is a microsoft article showing the differences in a nice table. Choosing ADO or DAO.
It also states:
"In particular, ADO is a good choice if you are developing an Access database solution that will later be upgraded to SQL Server — you can write your ADO code to minimize the number of changes that will be required to work against a SQL Server database. In addition, ADO is a good choice for developing new data access components that work with SQL Server, multidimensional data, and Web applications."
Seems like ADO might be the way to go.
I don't know anything about DLookUps though.
Our client wants to support both SQL Server and Oracle in the next project. Our experience comes from .NET/SQL Server platform. We will hire an Oracle developer, but our concern is with the DataAccess code. Will NHibernate make the DB Engine transparent for us? I don't think so, but i would like to hear from developers who have faced similar situations.
I know this question is a little vague, because i don't have Oracle experience, so i don't know what issues we will find.
You can easily use NHibernate to make your application database-agnostic by following some basic practices:
Design your object model first.
Do not use any database-specific code. You need somebody with good C# experience, not an Oracle developer. Do not rely on stuff like triggers, stored procedures, etc.
Let NHibernate generate the DB schemas at least initially (you can tweak things like indexes later) It will choose the best available datatypes for each DB.
Use a DB-agnostic POID generator (hilo or guid) instead of sequences or identity.
Try to avoid using SQL. HQL and Linq work fine in 99% of the cases.
Avoid NH features that are not supported by all of your target DB (for example, Future, MultiCriteria, etc)
NHibernate has a great community. You can always ask your questions in http://groups.google.com/group/nhusers besides posting here.
There are three things to consider - the ISession object, the SQL queries that are generated and your plain-old-clr-objects that are mapped to tables.
NHiberante will generate the required SQL queries based upon the chosen database dialect. If you configure NHibernate to use the SQL Server dialect it will generate SQL server correct SQL statements. This can easily be configured dynamically at runtime based on configuration.
You also need to configure your session to connect to the right type of database. Again, various configuration methods can support dynamic ISession creation at runtime.
Your actual data objects which are mapped to tables should not need to change based on database choice. One of NHibernates strengths is flexibility it provides in supporting multiple databases via a (fairly) simply configuration change and some up-front architectural thought.
See http://codebetter.com/blogs/karlseguin/archive/2009/03/30/using-nhibernate-with-multiple-databases.aspx for some examples of how you might abstract the underlying database away from the creation and usage of NHibernate.
I found this question here: OLEDB v/s ODBC
Which gave me more information, but did not really answer the question I'm asking, so I shall proceed from there.
I am working in C#. I'll spare you the long story about how I arrived at this conundrum, but basically I'm trying to decide between ODBC and oleDB.
We work with a lot of different clients who have vastly varied Databases (some SQL, some oracle, some something else that I've never heard of and didn't bother to remember the name of)
Now, from what I understand, ODBC is old, and was/is the standard. And now OleDB has come along and... is... different? but accomplishes the same thing (it talks to databases)
Why would I want to use one over the other? ODBC is (according to the above post) cross-platform, which is good, but he offers very little information as to what OleDB offers that ODBC does not.
In my other research, I've found (on the MSDN forums) People saying "use OleDB if you can, if you have to, resort to ODBC" Naturally, three's no reasoning given for this, so I'd like to hear some.
ODBC is a C API for accessing databases. There is a standard for it, it is supported by every major database vendor, it is very well documented, it is cross-platform. OLEDB is a similar interface that uses Microsoft's COM technology instead of the C API. This means that it is only easily useable on platforms that support COM.
At the end of the day, both libraries provide roughly equivalent basic functionality. Indeed, Some OLEDB drivers actually make use of ODBC rather than native database libraries.
So, if you are C# developer, working on Windows, OLEDB is the obvious choice between the two. If you are using C (or C++ not using COM), or need cross-platform support, then ODBC is the better bet.
As a C# developer and because you are accessing many different datasources you should go with OLEDB. I copied the following from this white paper because it gives some hints what to use when:
OLE DB is Not a Replacement for ODBC
The ODBC technology and third-party market have matured to a point at which ODBC is an ideal technology for accessing SQL databases. As a result, an integral part of OLE DB is a new OLE DB driver manager that enables OLE DB consumers to talk to ODBC providers. The following information can guide your choice of which technology to use:
If you are accessing standard relational databases from a non-OLE environment, ODBC is the best choice.
If you want to expose a data interface to non-SQL data, OLE DB is the best choice.
If you are programming in an OLE environment, OLE DB is the best choice.
If want to build interoperable database components, OLE DB is the only choice.
If you're programming in C#, you will not directly use either one. You'll use ADO.NET in some form.
True, the provider that you specify in your connection string may turn out to be an ODBC provider or an OleDB provider, but this will not matter to your code. ADO.NET will both APIs from your view.
I am writing an class using C++ (ATL).. I need to connect to a database. I am familiar with ADO but I see that all the functions are using IDispatch (late-binding/Automation). I am considering using OLEDB instead. What are the pros and cons of each? OLEDB seems like a lot of maintenance if the sql changes (tables, stored procs, etc). I did use the wizard to create some OLEDB headers and they dont seem as easy to "use" as ADO but speed does count. ADO also has an easy mechanism to convert the result to XML as well which is something I need. has any one used both before? which did you prefer? thanks!
to clarify, i am mentioning ATL only because there are ATL wizards for creating OLEDB consumer objects helps.
Using the ATL classes that wrap OLEDB is the way to go. If you consider that you're going to have to map your database schema to internal C++ classes regardless, then you're going to either do it with ADO and lots of painful IDispatch or with OLEDB which is a more natural in C++. If your database schema changes, you're going to have to modify your code regardless of the approach.
ADO is an OLE Automation wrapping of OLEDB, so the will not be any performance gains except that you'll have a lot less IDispatch thunking code to write.
There are many choices and approaches to getting that data into an XML form.