Quando eu deveria estar usando Odbc, OleDb, SQLClient? Quais são os trade-offs

Question

Eu estou começando com um banco de dados SQLServer. Assim parece que eu deveria usar namespace System.Data.SqlClient. Mas, há uma chance de que possamos encerrar nosso banco de dados SQLServer e ir para o MySQL ou Oracle. Por esta razão, eu estou chegando com um conjunto de normas sobre como nossos aplicativos .Net irá se comunicar com o banco de dados, de modo a torná-lo mais fácil de migrar para um sistema de banco de dados diferente no futuro, se necessário para fazê-lo.

Então aqui estão os padrões:

1. Use um ORM, se possível (por exemplo, NHibernate) (Sem LINQ, pois só suporta SqlServer, mas que sobre estrutura de entidade e seu apoio à Oracle e MySql?)
2. Se ORM é um over-kill, em seguida, usar consultas SQL parametrizadas.
3. Use procedimentos armazenados apenas para corrida de longa ou ações complexas que precisam ser executadas no banco de dados.

O que me leva à minha pergunta principal em questão. Qual namespace eu deveria estar usando o código meu DAL?

Parece-me que a escolha é entre System.Data.ODBC e System.Data.OleDB:

• Quais são as vantagens e desvantagens?
• é uma preferência sobre o outro?
• Quais são seus pensamentos sobre os 3 primeiros padrões?

Answer 1

System.Data.SQLClient

se conecta ao SQL Server 2000 e posterior, mas você vai ter um ótimo desempenho ao se conectar a essas bases de dados.

System.Data.OledbClient

Ligações para SQL 6.5

OleDbClient dá-lhe capacidade de se conectar a outro banco de dados, como Oracle ou Access. Mas para trabalhar com SQL Server você vai obter um melhor desempenho usando SQLClient.

Nota:. Para conectar ao Oracle, Microsoft também tem OracleClient

System.Data.ODBCClient

Ligações para bancos de dados legados somente, usando drivers ODBC. (Por exemplo MS acesso 97.)

fonte original

Answer 2

Você quer usar o driver SQL Server. Eu entendo o que você está tentando fazer, mas a maneira que você iria conseguir suportar múltiplos bancos de dados é através da inserção de uma outra camada de abstração. Você pode fazer isso muitas maneiras. Mas você colocar o código específico de banco de dados na borda de sua hierarquia de classes. Portanto, cada classe pode obter os benefícios da funcionalidade específica de banco de dados, mas os chamadores de nível superior não sabe ou cuidado com o banco de dados está sendo usado por baixo. Tanto quanto ORMs, eu prefiro LLBLGen , mas esta é apenas a minha preferência.

Além disso, só para esclarecer, LINQ não é específico para SQL Server. Isso é LINQ to SQL. LINQ é uma tecnologia de consulta que você pode usar em LINQ to SQL, LINQ to Entities, LINQ para objetos, e até mesmo LLBLGen suporta LINQ.

Answer 3

Não importa se você usar SQLClient ou ODBC, por agora, se você usar procedimentos armazenados ou outros recursos específicos do banco de dados, você vai ter que reescrever aqueles se você mudar os motores de banco de dados.

Answer 4

Eu tinha acabado de usar SqlClient e re-write / re-gerar o DAL se alterado.

A menos que você está indo para implementar e testar em múltiplas plataformas, agora, eu não tenho certeza que o esforço extra agora é um grande negócio ou qualquer menos do que o esforço para refazer a DAL, eo fato de que você tem tem uma DAL em todos os meios que você tem tudo em um só lugar para uma mudança depois de qualquer maneira.

Answer 5

Se você tem alguma idéia que você estará trocando bancos de dados (ou suportando múltiplos backends), em seguida, um ORM é o caminho a percorrer. Caso contrário, você ainda terá que refatorar / reescrever um monte de seu DAL, a fim de apoiar a mudança. Se seu aplicativo é pequeno, não vai ser ruim, mas nada de substancial e você vai estar machucando.

Answer 6

Você vai descobrir que usando o SqlClient SQL Server é muito mais rápido e mais fácil de desenvolver com que OleDB e ODBC - a menos que é muito provável que você vai precisar para suportar múltiplas plataformas você vai achar que os benefícios superam os riscos que você vai necessidade de reescrever o seu DAL.

Além disso, usando / ODBC OleDB é de apenas 1 maneira de manter a independência de plataforma -. Você pode achar que é mais eficaz para ter várias implementações de seu DAL, cada um usando um cliente nativo para a plataforma que está sendo usado

Answer 7

Eu ouvi dizer que a menos que seja uma característica fundamental, você não deve se preocupar muito com a manutenção de independência de plataforma. Dito isto,

SQLClient lhe dará acesso nativo e deve ser mais alto desempenho (ele não tem que fazer quaisquer abstrações / traduções).

A única coisa que você tem que mudar para obter OLEDB de trabalho vs. ODBC é a seqüência de conexão. OLEDB tem um pouco mais de inteligência do lado do cliente para que ele oferece melhor desempenho.