Каковы плюсы и минусы OleDB по сравнению с SQLClient?

Ответ 1

OleDb более общий. Если вы когда-нибудь перейдете к другому типу базы данных в будущем, у вас будет хороший драйвер Ole, и вам не придется менять столько кода.

С другой стороны, родной драйвер сервера Sql должен быть быстрее, как вы сказали, и имеет более удобную поддержку параметров (параметры могут использовать имена и не должны быть в порядке).

В моем личном опыте я никогда не замечал разницы в скорости, так что, как и вы, я не мог найти ничего, чтобы поддержать это. Я подозреваю, что преимущество производительности действительно, но вам придется обрабатывать миллионы записей, прежде чем вы сможете его измерить.

То, что я заметил, сделало значимую разницу в сообщениях об ошибках. У меня возникли проблемы со старым приложением OleDb, и я переключил его на SqlClient из отчаяния. Разумеется, это все еще не сработало, но лучшие сообщения об ошибках предоставили достаточно новой информации, что я смог исправить эту проблему.

Ответ 2

OLEDB намного быстрее, чем SQLClient, EXCEPT, когда он получает доступ через ADO.NET. Драйверы для OLEDB записываются в собственный неуправляемый код, однако при доступе к этим драйверам через ADO.NET вам необходимо пройти несколько уровней (включая слой абстракции и слой взаимодействия COM). Уровень абстракции обеспечивает управление ресурсами, например, управление ручками памяти для обеспечения правильной сборки мусора, изменения типов данных и параметров для типов .NET и преобразования буфера oledb в привязку строк и столбцов. Слой взаимодействия COM обрабатывает передачу сообщений от .NET до COM и наоборот, включая указатели блокировки/разблокировки/конвертации.

Не слушайте никого, кто делает ложные обвинения в производительности OleDB, не понимая, как они тестировали его и какую среду они использовали (управляемый код и управляемый код). Единственное, что замедляет OleDB, - это количество сантехники, которое требуется, чтобы заставить собственный код играть хорошо с управляемым кодом. Также имейте в виду, что библиотека SqlClient.NET имеет собственную систему сантехники и IS NOT A NATIVE.NET, как это считают большинство людей. Библиотеки SqlClient в .NET используют классы SNINativeMethodWrapper и SNIPacket, которые являются оболочками, которые маршалируют данные между неуправляемым кодом (sqlncli.dll) и управляемым кодом .NET. Это недокументированная правда и причина, по которой .NET SqlClient никогда не сможет выполнить OleDB, когда вы используете OleDB в собственном неуправляемом коде.

Таким образом, если вы используете 100% управляемый код, вы получите более высокую производительность из System.data.SqlClient. Если у вас смешанная среда, вы получите гораздо лучшую производительность, разговаривая напрямую с OleDB или с sqlncli.dll(SQL2005) или sqlncli10.dll(SQL 2008). Имейте в виду, что как OleDB, так и ODBC обновляются Microsoft и последние драйверы OleDB. Говорите с последними неуправляемыми исходными SQL-клиентскими библиотеками. Microsoft рекомендует использовать OleDB в неуправляемых приложениях, когда требуется высокая производительность.

Для получения дополнительной информации см. "Электронная документация по SQL Server 2008\База данных Engine\Development\Руководство разработчика\Программирование собственного клиента SQL Server 2008\Собственный клиент SQL Server 2008 (OLE DB)".

Ответ 3

Я с Joel на этом, SqlClient лучше всего использовать, если вы планируете придерживаться SQL Server. Есть рост производительности, но вы должны начать работать с большими наборами, а большое количество транзакций, как правило, начинают видеть преимущества этого.

В целом, предоставленные ошибки и функциональные возможности гораздо более адаптированы к тому, что может сделать SQL Server, и, таким образом, это "лучшая" реализация. Он также поддерживает MARS, который для некоторых делает его "обязательным".

Ответ 4

Вот несколько 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.

Ответ 5

Вы всегда можете написать пример приложения с некоторыми типичными операциями с использованием SqlClient и OleDB и сравнить их для сравнения производительности. Я сомневаюсь, что разница будет значительна, но есть только один способ узнать.

Я не думаю, что у вас есть проблемы с использованием OleDb, если вы не используете экзотические типы данных, такие как XML, и в этом случае вам может потребоваться немного усложнить работу.