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

Question

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

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

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

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

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

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

Answer 1

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 2

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

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

Answer 3

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

Answer 4

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

Если вы не собираетесь реализовывать и тестировать на нескольких платформах прямо сейчас, я не уверен, что дополнительные усилия сейчас имеют большое значение или меньше, чем усилия по переделке DAL и тот факт, что у вас есть DAL. «Вообще» означает, что у вас все равно есть все в одном месте, чтобы можно было изменить его позже.

Answer 5

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

Answer 6

Вы обнаружите, что с помощью SQL Server разрабатывать SqlClient гораздо быстрее и проще, чем OleDB и ODBC. ваш ДАЛ.

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

Answer 7

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

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

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