一些上下文:我正在研究的系统之一是.net 2.0 Web应用程序.用于前端的VB.net和用于后端的SQL Server 2005.由于各种原因已经丢失,原设计师决定使用.Net OleDB连接而不是SQLClient连接.
经过几年的发展,这个特殊的系统正处于从"beta"到"1.0"状态的过程中.我们此时讨论的一件事就是转向SQLClient连接.虽然我知道最好的做法是使用它,并且这是获得SQL Server 2005(我们没有使用,显然)的更好的功能的唯一方法,使用这个功能的优势是什么?其他?我应该知道的任何隐藏的陷阱?任何人都可以指出一些显示相对速度的基准吗?(我听说SQLClient应该更快,但我从未见过任何数字来支持它.)
谢谢,所有.
OleDb更通用.如果您将来移动到不同的数据库类型,它很可能会有一个Ole驱动程序,您不必更改尽可能多的代码.
在另一方面,SQL Server本机驱动程序应该是如你所说更快,具有更好的参数支持(参数可以使用名称,不具有符合规定).
根据我的个人经验,我从未注意到速度差异; 我也找不到任何支持索赔的东西.我怀疑性能优势是真实的,但在开始测量之前你必须处理数百万条记录.
我所注意到的是错误消息带来了有意义的差异.我在使用旧的OleDb应用程序时遇到了问题,我出于绝望而将其切换为SqlClient.当然,它仍然无法正常工作,但更好的错误消息提供了足够的新信息,我能够解决问题.
OLEDB比SQLClient快得多,除非通过ADO.NET访问.OLEDB的驱动程序是用本机非托管代码编写的,但是当您通过ADO.NET访问这些驱动程序时,您必须经历多个层(包括抽象层和COM互操作层).抽象层负责资源管理,例如管理内存句柄以确保正确进行垃圾收集,将数据类型和参数更改为.NET类型以及将oledb缓冲区转换为行和列绑定.COM互操作层负责编组从.NET传递消息到COM,反之亦然,包括锁定/解锁/转换指针.
如果没有理解他们如何测试它以及他们使用什么环境(托管代码与托管代码),那么不要听任何对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)".