¿Cuáles son los pros y los contras de OleDB versus SQLClient?

Question

Algunos contextos: uno de los sistemas en los que estoy trabajando es una aplicación web .net 2.0. VB.net para el front-end y SQL Server 2005 para el back-end. Por una variedad de razones que se han perdido en el tiempo, el diseñador original decidió usar la conexión .Net OleDB en lugar de la conexión SQLClient.

Después de algunos años de desarrollo, este sistema en particular está en la cúspide de cruzar la línea de "beta" a estado "1.0". Una de las cosas de las que hemos estado hablando en este momento es pasar a la conexión SQLClient. Si bien soy consciente de que es una buena práctica usarlo, y que es la única manera de obtener las características más sofisticadas de SQL Server 2005 (que no estamos usando, obviamente), ¿cuáles son las ventajas de usar uno sobre el ¿otro? ¿Alguna trampa oculta que deba conocer? ¿Y alguien puede señalarme en algunos puntos de referencia que muestran velocidades relativas? (Escuché que se supone que el SQLClient es más rápido, pero nunca he visto ningún número que lo respalde).

Gracias, todos.

Answer 1

OleDb es más genérico. Si alguna vez se mueve a un tipo de base de datos diferente en el futuro, hay buenas posibilidades de que tenga un controlador Ole y no tenga que cambiar tanto código.

Por otro lado, se supone que el controlador nativo del servidor Sql es más rápido que el que dijo y tiene un mejor soporte para los parámetros (los parámetros pueden usar nombres y no tienen en orden).

En mi experiencia personal, nunca he notado la diferencia de velocidad, así que como usted no pude encontrar nada que lo respalde. Sospecho que la ventaja de rendimiento es real, pero que tendría que procesar millones de registros antes de poder comenzar a medirlo.

Lo que sí noté que marcó una diferencia significativa fueron los mensajes de error. Estaba teniendo problemas con una vieja aplicación OleDb, y la cambié a SqlClient por desesperación. Todavía no funcionó, por supuesto, pero los mejores mensajes de error proporcionaron suficiente información nueva que pude solucionar el problema.

Answer 2

Estoy con Joel en este caso, SqlClient es el mejor para usar si planea seguir con SQL Server. Hay ganancias en el rendimiento, pero debe comenzar a trabajar con conjuntos grandes, y un gran número de transacciones para comenzar a ver los beneficios de esto.

En general, los errores y la funcionalidad proporcionados se adaptan mucho más a lo que SQL Server puede hacer, por lo tanto una implementación "mejor" si se quiere. También tiene soporte para MARS, que para algunos lo convierte en el interruptor "imprescindible".

Answer 3

Siempre puede escribir una aplicación de muestra con algunas operaciones típicas usando SqlClient y OleDB y compararlas para comparar el rendimiento. Dudo que la diferencia sea significativa, pero solo hay una forma de averiguarlo.

No creo que tenga ningún problema al utilizar OleDb a menos que esté usando tipos de datos exóticos como XML, en cuyo caso podría necesitar trabajar un poco más.

Answer 4

OLEDB es mucho más rápido que el SQLClient, EXCEPTO cuando se accede a través de ADO.NET. Los controladores para OLEDB están escritos en código nativo no administrado; sin embargo, cuando accede a estos controladores a través de ADO.NET, debe pasar por varias capas (incluyendo una capa de abstracción y una capa de interoperabilidad COM). La capa de abstracción se ocupa de la administración de recursos, como la administración de identificadores de memoria para garantizar que la recolección de basura se realice correctamente, el cambio de tipos de datos y parámetros a tipos .NET y la conversión del búfer de oledb a enlaces de filas y columnas. La capa de interoperabilidad COM se encarga de coordinar el paso de mensajes de .NET a COM y viceversa, incluyendo el bloqueo/desbloqueo/conversión de punteros.

No escuche a nadie que haga acusaciones falsas sobre el rendimiento de OleDB sin entender cómo lo probaron y qué entorno usaron (código administrado frente a código administrado). Lo único que desacelera OleDB es la cantidad de plomería que se requiere para que el código nativo funcione bien con el código administrado. También tenga en cuenta que la biblioteca SqlClient .NET tiene su propia instalación de fontanería y NO ES UNA biblioteca NATIVE .NET como la mayoría de la gente cree que es. Las bibliotecas SqlClient en .NET utilizan las clases SNINativeMethodWrapper y SNIPacket, que son contenedores que recopilan datos entre código no administrado (sqlncli.dll) y código .NET administrado. Esta es la verdad no documentada y la razón por la cual .NET SqlClient nunca podrá realizar el OleDB cuando utilice OleDB en código nativo no administrado.

En resumen, si está utilizando el 100% de código administrado, obtendrá un mejor rendimiento del System.data.SqlClient. Si tiene un entorno mixto, obtendrá un rendimiento mucho mejor si habla directamente con OleDB o con sqlncli.dll (SQL2005) o sqlncli10.dll (SQL 2008). Tenga en cuenta que tanto OleDB como ODBC están siendo actualizados por Microsoft y los últimos controladores OleDB HACEN hablar con las últimas librerías de SQL nativas no administradas. Microsoft recomienda usar OleDB en aplicaciones no administradas cuando se requiere un alto rendimiento.

Consulte "Libros en pantalla de SQL Server 2008 \ Motor de base de datos \ Desarrollo \ Guía del desarrollador \ Programación de SQL Server 2008 Native Client \ SQL Server 2008 Native Client (OLE DB)" para obtener más información.

Answer 5

Aquí es un poco de PowerShell código para hacer un directo comparar:

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 

llegué

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

Y como resultado, para consultas ad-hoc de este tipo prefiero Ole-DB, ya que solo tengo que ajustar la cadena de conexión para extraer datos de una base de datos Oracle.