OleDB 与 SQLClient 相比有何优缺点？

发布于 2024-07-12 12:59:49 字数 383 浏览 5 评论 0原文

一些背景：我正在开发的系统之一是 .net 2.0 Web 应用程序。前端使用VB.net，后端使用SQL Server 2005。由于各种已被时间遗忘的原因，最初的设计者决定使用.Net OleDB 连接而不是 SQLClient 连接。

经过几年的发展，这个特殊的系统即将从“beta”进入“1.0”状态。我们目前讨论的一件事是转向 SQLClient 连接。虽然我知道使用它是最佳实践，并且它是获得 SQL Server 2005 中更高级功能的唯一方法（显然我们没有使用它），但使用它比使用它有什么优势？其他？有什么我应该知道的隐藏问题吗？谁能给我指出一些显示相对速度的基准吗？（我听说 SQLClient 应该更快，但我从未见过任何数字来支持这一点。）

谢谢大家。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

那一片橙海， 2024-07-19 12:59:49

OleDb 更通用。如果您将来迁移到不同的数据库类型，它很可能会有 Ole 驱动程序，并且您不必更改那么多代码。

另一方面，正如您所说，Sql Server 本机驱动程序应该更快，并且具有更好的参数支持（参数可以使用名称，并且不必按顺序排列）。

根据我个人的经验，我从来没有注意到速度的差异；我也找不到任何东西来支持这一说法。我怀疑性能优势是真实的，但您必须处理数百万条记录才能开始测量它。

我确实注意到错误消息产生了有意义的变化。我在使用旧的 OleDb 应用程序时遇到了问题，出于绝望，我将其切换到 SqlClient。当然，它仍然不起作用，但是更好的错误消息提供了足够的新信息，我能够解决问题。

回复收藏 0 原文

遇到 2024-07-19 12:59:49

OLEDB 比 SQLClient 快得多，除非通过 ADO.NET 访问。 OLEDB 的驱动程序是用本机非托管代码编写的，但是，当您通过 ADO.NET 访问这些驱动程序时，必须经过多个层（包括抽象层和 COM 互操作层）。抽象层负责资源管理，例如管理内存句柄以确保垃圾收集正确发生、将数据类型和参数更改为 .NET 类型以及将 oledb 缓冲区转换为行和列绑定。 COM 互操作层负责编组从 .NET 到 COM 的消息传递，反之亦然，包括锁定/解锁/转换指针。

不要听任何人对 OleDB 性能的错误指控，而不了解他们如何测试 OleDB 以及他们使用的环境（托管代码与托管代码）。唯一拖慢 OleDB 速度的是让本机代码与托管代码良好配合所需的管道数量。另请记住，SqlClient .NET 库有自己的管道，并不像大多数人认为的那样是原生 .NET 库。 .NET 中的 SqlClient 库使用 SNINativeMethodWrapper 和 SNIPacket 类，它们是在非托管代码 (sqlncli.dll) 和托管 .NET 代码之间封送数据的包装器。这是未记录的事实，也是当您在本机非托管代码中使用 OleDB 时 .NET SqlClient 永远无法超越 OleDB 的原因。

总之，如果您使用 100% 托管代码，您将从 System.data.SqlClient 获得更好的性能。如果您有混合环境，则直接与 OleDB 或 sqlncli.dll (SQL2005) 或 sqlncli10.dll (SQL 2008) 对话将获得更好的性能。请记住，Microsoft 正在更新 OleDB 和 ODBC，并且最新的 OleDB 驱动程序确实可以与最新的非托管本机 SQL 客户端库通信。当需要高性能时，Microsoft 建议在非托管应用程序中使用 OleDB。

有关详细信息，请参阅“SQL Server 2008 联机丛书\数据库引擎\开发\开发人员指南\SQL Server 2008 本机客户端编程\SQL Server 2008 本机客户端 (OLE DB)”。

OLEDB is much faster than the SQLClient, EXCEPT when it is access through ADO.NET. The drivers for OLEDB are written in native unmanaged code however, when you access these drivers through ADO.NET, you have to go through several layers (including an abstraction layer and a COM interop layer). The abstraction layer takes care of resource management such as managing memory handles to ensuring that garbage collection occurs correctly, changing data types and parameters to .NET types and converting the oledb buffer to row and column bindings. The COM interop layer takes care of marshalling passing messages from .NET to COM and vice versa including locking/unlocking/converting pointers.

Don't listen to anyone that makes false accusations about OleDB's performance without understanding how they tested it and what environment they used (managed code vs managed code). The only thing that slows OleDB down is the amount of plumbing that is required to get the native code to play nice with the managed code. Also keep in mind that the SqlClient .NET library has its own plumbing and IS NOT A NATIVE .NET library like most people think it is. The SqlClient libraries in .NET use the the SNINativeMethodWrapper and SNIPacket classes which are wrappers that marshal data between unmanaged code (sqlncli.dll) and managed .NET code. This is the undocumented truth and the reason why the .NET SqlClient will never be able to out perform the OleDB when you use OleDB in native unmanaged code.

In summary, if you are using 100% managed code, you will get better performance from the System.data.SqlClient. If you have a mixed environment, you will get far better performance talking to OleDB directly or to either sqlncli.dll (SQL2005) or sqlncli10.dll (SQL 2008). Keep in mind that both OleDB and ODBC are being updated by Microsoft and the latest OleDB drivers DO talk to the latest unmanaged native SQL client libraries. Microsoft recommend using OleDB in unmanaged applications when high performance is required.

See "SQL Server 2008 Books Online\Database Engine\Development\Developer's Guide\SQL Server 2008 Native Client Programming\SQL Server 2008 Native Client (OLE DB)" for more information.

回复收藏 0 原文

§普罗旺斯的薰衣草 2024-07-19 12:59:49

我同意 Joel 的观点，如果您打算继续使用 SQL Server，SqlClient 是最好的选择。虽然性能有所提升，但您必须开始处理大型数据集和大量事务，通常才能开始看到这样做的好处。

总的来说，提供的错误和功能更适合 SQL Server 的功能，因此如果您愿意的话，这是一个“更好”的实现。它还支持 MARS，这对于某些人来说是“必须做”的开关。

回复收藏 0 原文

情独悲 2024-07-19 12:59:49

下面是一些用于直接比较的 PowerShell 代码：

Ole-DB:

$ConnectionString      = "server=localhost;database=MyDatabase;trusted_connection=yes;Provider=SQLNCLI10;"
$sql = "SELECT * FROM BigTable"

$conn = New-Object System.Data.OleDb.OleDbConnection($ConnectionString)
$conn.open()
$cmd = New-Object system.Data.OleDb.OleDbCommand($sql,$conn)
#$cmd.CommandTimeout = $timeout
$da = New-Object system.Data.OleDb.OleDbDataAdapter($cmd)
$dt = New-Object system.Data.datatable
[GC]::Collect()
$start = get-date
[void]$da.fill($dt)
$now = get-date
[int]($now - $start).Milliseconds
$conn.close()
#$dt

SQLClient:

$ConnectionString      = "Data Source=localhost;Initial Catalog=MyDatabase;Integrated Security=True"
$sql = "SELECT  * FROM BigTable"


$conn=new-object System.Data.SQLClient.SQLConnection($ConnectionString) 
$conn.Open() 
$cmd=new-object System.Data.SQLClient.SQLCommand($sql,$conn)
#   $cmd.CommandTimeout=$timeout
$dt = New-Object system.Data.datatable
$da=New-Object System.Data.SQLClient.SQLDataAdapter($cmd)
[GC]::Collect()
$start = get-date
[void]$da.fill($dt)
$now = get-date
[int]($now - $start).Milliseconds
$conn.close()
#$dt

我得到了

Ole-DB : SQL-Client
538 - 839
767 - 456
592 - 678

因此，对于临时查询对于这种类型，我更喜欢 Ole-DB，因为我只需调整连接字符串即可从 Oracle 数据库中提取数据。

Here is some PowerShell Code to do a direct compare:

Ole-DB:

$ConnectionString      = "server=localhost;database=MyDatabase;trusted_connection=yes;Provider=SQLNCLI10;"
$sql = "SELECT * FROM BigTable"

$conn = New-Object System.Data.OleDb.OleDbConnection($ConnectionString)
$conn.open()
$cmd = New-Object system.Data.OleDb.OleDbCommand($sql,$conn)
#$cmd.CommandTimeout = $timeout
$da = New-Object system.Data.OleDb.OleDbDataAdapter($cmd)
$dt = New-Object system.Data.datatable
[GC]::Collect()
$start = get-date
[void]$da.fill($dt)
$now = get-date
[int]($now - $start).Milliseconds
$conn.close()
#$dt

SQLClient:

$ConnectionString      = "Data Source=localhost;Initial Catalog=MyDatabase;Integrated Security=True"
$sql = "SELECT  * FROM BigTable"


$conn=new-object System.Data.SQLClient.SQLConnection($ConnectionString) 
$conn.Open() 
$cmd=new-object System.Data.SQLClient.SQLCommand($sql,$conn)
#   $cmd.CommandTimeout=$timeout
$dt = New-Object system.Data.datatable
$da=New-Object System.Data.SQLClient.SQLDataAdapter($cmd)
[GC]::Collect()
$start = get-date
[void]$da.fill($dt)
$now = get-date
[int]($now - $start).Milliseconds
$conn.close()
#$dt

I got

Ole-DB : SQL-Client
538 - 839
767 - 456
592 - 678

And as a result, for ad-hoc queries of this type I prefer Ole-DB, as I have only to adjust the connection string to pull data from an Oracle database.

回复收藏 0 原文