SQL Server 2012 через собственный C ++ (без ATL) предпочтительный метод доступа из Windows
У меня есть родное приложение C ++, которое работает под Windows 64, оно не использует ATL (и не будет). Я хочу иметь возможность подключаться из моего приложения к SQL Server 2012 по сети.
У меня есть следующие требования:
-
Производительность — ключ
-
C ++ будет вставлять только записи (скажем, путем вызова Stored Procs), ничего больше (без выбора, удаления или обновления).
-
Записи вставки должны быть неблокирующими (асинхронными).
Я сузил свой выбор до OLE DB и ODBC, поскольку они удовлетворяют критериям, указанным выше. Тем не менее, кажется, что в Интернете есть множество противоречивых советов о том, что использовать. Примеры:
-
«Если у вас есть выбор между использованием ODBC или OLE DB для доступа к базе данных SQL Server, выберите OLE DB, так как обычно он быстрее. [7.0, 2000, 2005] Обновлен 2-20-2006» источник: http://www.sql-server-performance.com/2007/odbc-oledb/
-
Источник «OLE DB устарел»: http://weblogs.sqlteam.com/dang/archive/2011/09/04/rip-ole-db.aspx
-
«Избегайте использования OLE DB для разработки новых приложений SQL Server. Обновите технологическую схему, чтобы перейти к миграции существующих приложений SQL Server, использующих SQLNCLI, SQLNCLI10, SQLNCLI11 или поставщики OLE DB SQLOLEDB для драйвера ODBC собственного клиента SQL Server. «источник: http://weblogs.sqlteam.com/dang/archive/2011/09/04/rip-ole-db.aspx но SQLNCLI11 — это драйвер ODBC для собственного клиента SQL Server, основанный на MSDN: http://msdn.microsoft.com/library/ms130904.aspx Итак, это была опечатка в блоге?
Я действительно запутался и хотел бы узнать больше о лучших технологиях доступа к SQL Server по моим критериям.
Решение
И OleDB, и ODBC используют SQLNCLI. Увидеть Имена и свойства компонентов по версии Таблица, наблюдатель, как Sqlncli.dll / Sqlncli10.dll / Sqlncli11.dll является драйвером для ODBC и OleDB.
Если вы посмотрите на Дорожная карта технологий доступа к данным вы увидите, что и ODBC, и OleDB актуальны и поддерживаются. Что такое осуждается SQLOLEDB и SQLODBC, которые являются старыми дисками MDAC SQL Server для OleDB и ODBC (то есть. sqlsrv32.dll и Sqloledb.dll). Для них обоих есть пути обновления и рекомендации, см. Обновление приложения до собственного клиента SQL Server из MDAC.
Таким образом, вывод заключается в том, что вы можете безопасно продолжать использовать как ODBC, так и OleDB, просто убедитесь, что вы используете современные драйверы на основе SLNCLI, а не старые устаревшие драйверы MDAC.
Основным риском при использовании устаревших драйверов является отсутствие поддержки новых типов данных (например, география, иерархия, datetime2 и т. Д.).
Другие решения
Я испытал много лет назад OleDB (с ATL) и ODBC (с MFC).
Но интерфейс редко является узким местом, обычно вставка / обновление доминируют над временем (на самом деле, я выполнил большую вставку / обновление с помощью массового копирования + хранимых процедур).
В любом случае, я бы предложил промежуточный (третий?) Способ: OTL, которые делают C ++ / ODBC терпимым.