database - native OLE DB 和 ADO.NET 之间的速度差异

Question

我正在寻找建议以及人们拥有的任何基准或观察结果。我们正在寻求重写我们的数据访问层，并试图在 native C++ OLEDB 或 ADO.NET 之间做出决定以连接数据库。目前我们专门针对 Oracle，这意味着我们将使用 Oracle OLE DB 提供程序和 ODP.NET。

要求:1. 所有应用程序都将在托管代码中，因此使用 native C++ OLEDB 将需要 C++/CLI 才能工作(没有 PInvoke 方式会减慢)。2. 应用程序将来必须与多个数据库一起工作，目前只针对Oracle。

问题:1. 使用 ADO.NET 来完成此操作或使用封装在托管 C++ 接口(interface)中以供托管代码访问的 native C++ OLE DB 会更高效吗？

如果您有任何想法、帮助或可以在网络上查看的地方，我们将不胜感激。

Answer 1

考虑到您需要的不仅仅是 Oracle 的通用解决方案，我认为不可能给出普遍适用于这种情况的单一答案。问题是一个供应商的 .NET 提供程序可能比他们的 OLE DB 提供程序更快，而另一个供应商则相反。这两种数据访问技术的架构截然不同。

不过，我的直觉是速度差异不会那么大。因为这听起来像是您将自己的数据访问层放在 OLE DB 之上，所以在您编写之前很难直接比较。但总的来说，任何数据修改语句(例如，UPDATE mytable set…)在这两种情况下可能都不会完全不同。使用这两种技术，您可以在适当的情况下指定参数数据，然后将命令发送到服务器。大部分成本可能是网络延迟和服务器执行时间。最大的区别可能会在读取数据集时发挥作用。

读取数据将是显示速度差异的因素。根据您的计划，您可能希望读取低级别的数据。例如，对于 OLE DB，您可以调用 IRowset::GetNextRows。使用 .NET，您可能会通过 DbDataReader::Read() 读取数据集。我不知道这是否典型，但在我处理的代码中，OLE DB GetNextRows() 方法比 .NET Read() 实现复杂得多。我不确定这是否一定会导致执行速度变慢……但有可能。

在我看来，最好的选择是使用 ADO.NET。由于它是 Microsoft 当前的数据访问技术，我怀疑供应商更新其 .NET 提供程序的频率将高于其 OLE DB 提供程序。因此，如果在实现中存在性能问题，.NET 提供程序可能会得到修复，而他们的 OLE DB 提供程序可能不会及时(或根本没有)得到修复。此外，如果需要，您可以使用 .NET 提供程序(例如， Entity Framework )获得更大的灵 active 。如果您希望使用 OLE DB，您将需要为 OLE DB 提供程序使用 .NET 提供程序，这是 OLE DB 之上的另一层(假设它甚至可以工作，我不知道)。