我正在寻找建议以及人们的任何基准或观察。我们正在寻找重写我们的数据访问层，并试图在本机C ++ OLEDB或ADO.NET之间决定是否与数据库连接。目前我们专门针对Oracle，这意味着我们将使用Oracle OLE DB提供程序和ODP.NET。
要求： 1.所有应用程序都将使用托管代码，因此使用本机C ++ OLEDB将需要C ++ / CLI才能工作（没有PInvoke方式来减慢）。 2.应用程序将来必须与多个数据库一起使用，目前仅针对Oracle。
问题： 1.使用ADO.NET实现此目的或使用托管C ++接口中包含的本机C ++ OLE DB以便托管代码访问是否更具性能？
非常感谢任何想法，帮助或在网络上查看的地方。
答案 0 :(得分：1)
考虑到您想要的不仅仅是Oracle的通用解决方案，我认为不可能给出一个通常适用于这种情况的单一答案。问题是，一个供应商的.NET提供商可能比他们的OLE DB提供商更快，反之亦然另一个供应商。这两种数据访问技术的架构都有很大不同。
我的直觉是，速度差异不会那么大。因为听起来你会把你自己的数据访问层放在OLE DB之上，所以在你写这篇文章之前直接进行比较很难。但一般来说，任何数据修改语句（例如，UPDATE mytable set ......）在任何一种情况下都可能不会完全不同。使用这两种技术，您可以根据需要指定参数数据，然后将命令发送到服务器。大部分成本可能是网络延迟和服务器执行时间。在阅读数据集时，最大的差异可能会发挥作用。
读取数据将成为可能显示速度差异的因素。根据您的计划，您可能希望以较低级别读取数据。例如，使用OLE DB，您可以调用IRowset :: GetNextRows。使用.NET，您可以通过DbDataReader :: Read（）读取数据集。我不知道它是否典型，但在我使用的代码中，OLE DB GetNextRows（）方法比.NET Read（）实现复杂得多。我不确定这是否必然转化为执行速度较慢......但可能会这样。
在我看来，最好的选择是使用ADO.NET。由于它是微软目前的数据访问技术，我怀疑供应商会比他们的OLE DB提供商更频繁地更新他们的.NET提供商。因此，如果在实现中存在性能问题，则.NET提供程序可能会被修复，而它们的OLE DB提供程序可能无法及时（或根本不）修复。此外，如果需要，您可以通过.NET提供程序获得更大的灵活性（例如，实体框架）。如果你想用OLE DB，你将需要使用.NET提供程序的OLE DB提供程序，这是OLE DB之上的另一层（假设它甚至可以工作，我不知道）。