Speed Difference between native OLE DB and ADO.NET

Question

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.

Answer 1

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).