Когда я должен использовать Odbc, OleDb, SQLClient? Каковы компромиссы

Question

Я начинаю с базы данных SQLServer. Казалось бы, мне следует использовать пространство имен System.Data.SqlClient. Но есть вероятность, что мы можем закрыть нашу базу данных SqlServer и перейти к MySql или Oracle. По этой причине я придумываю набор стандартов о том, как наши приложения .Net будут взаимодействовать с базой данных, чтобы упростить переход в другую систему базы данных в будущем, если нам потребуется это сделать.

Итак, вот стандарты:

1. Используйте ORM, если это возможно (например, NHibernate) (нет LINQ как только поддерживает SqlServer, но как насчет Структура сущности и ее поддержка Oracle и MySql?)
2. Если ORM является избыточным, используйте параметризованные запросы SQL.
3. Используйте хранимые процедуры только для длительных или сложных действий, которые должны быть выполнены на базы данных.

Что подводит меня к моему основному вопросу. Какое пространство имен я должен использовать для кодирования моего DAL?

Мне кажется, что выбор между System.Data.ODBC и System.Data.OleDB:

• Каковы компромиссы?
• Один из них предпочтительнее другого?
• Что вы думаете о первых трех стандартах?

Answer 1

Независимо от того, используете ли вы сейчас SQLClient или Odbc, если вы используете хранимые процедуры или другие специфичные для базы данных функции, вам придется их переписывать, если вы меняете механизмы базы данных.

Answer 2

System.Data.SqlClient

Подключается только к SQL Server 2000 и более поздним версиям, но вы получите оптимальную производительность при подключении к этим базам данных.

System.Data.OledbClient

Подключается к SQL 6.5

OLEDBClient дает вам возможность подключаться к другой базе данных, такой как ORACLE или Access. Но для работы с SQL Server вы получите более высокую производительность, используя SQLClient.

Примечание. Для подключения к ORACLE в Microsoft также имеется ORACLEClient.

System.Data.ODBCClient

Подключается только к устаревшим базам данных с использованием драйверов ODBC. (Например, MS Access 97.)

Оригинальный источник

Answer 3

Вы хотите использовать драйвер SQL Server. Я понимаю, что вы пытаетесь сделать, но способ поддержки нескольких баз данных заключается в добавлении еще одного уровня абстракции. Вы можете сделать это многими способами. Но вы помещаете специфичный для базы данных код на границу иерархии классов. Следовательно, каждый класс может получить преимущества специфической функциональности базы данных, но вызывающие абоненты более высокого уровня не знают или не заботятся о том, какая база данных используется ниже. Что касается ORM, я предпочитаю LLBLGen , но это только мои предпочтения.

Кроме того, просто чтобы уточнить, LINQ не является специфическим для SQL Server. Это LINQ-to-SQL. LINQ - это технология запросов, которую вы можете использовать в LINQ-to-SQL, LINQ-to-Entities, LINQ-to-objects и даже LLBLGen поддерживает LINQ.

Answer 4

Вы обнаружите, что с использованием SQL Server SqlClient гораздо быстрее и проще в разработке, чем с OleDB и ODBC, - если только крайне маловероятно, что вам потребуется поддержка нескольких платформ, вы обнаружите, что преимущества перевешивают риски, которые вы нужно переписать свой DAL.

Кроме того, использование OleDB / ODBC - это всего лишь один из способов обеспечения независимости от платформы - вам может оказаться более эффективным иметь несколько реализаций вашего DAL, каждая из которых использует клиента, родного для используемой платформы.

Answer 5

Если у вас есть какие-либо предположения, что вы будете обмениваться базами данных (или поддерживать несколько бэкэндов), тогда ORM - это то, что вам нужно. В противном случае вам все равно придется реорганизовать / переписать большую часть вашего DAL, чтобы поддержать изменение. Если ваше приложение маленькое, оно не будет плохим, но что-то существенное и вам будет больно.

Answer 6

Я бы просто использовал SqlClient и переписал / заново сгенерировал DAL, если он изменился.

Если вы не собираетесь внедрять и тестировать на нескольких платформах прямо сейчас, я не уверен, что дополнительные усилия сейчас - это нечто большое или даже меньшее, чем попытка переделать DAL, и тот факт, что вы если у вас есть DAL, это значит, что у вас есть все в одном месте для дальнейших изменений.

Answer 7

Я слышал, что, если это не ключевая функция, вам не следует слишком беспокоиться о сохранении независимости платформы. Тем не менее,

SQLClient предоставит вам собственный доступ и должен быть более производительным (он не должен делать никаких абстракций / переводов).

Единственное, что вам нужно изменить, чтобы OLEDB работал против ODBC, - это строка вашего соединения. OLEDB имеет немного больше интеллекта на стороне клиента, поэтому он предлагает лучшую производительность.