Quand dois-je utiliser Odbc, OleDb, SQLClient? Quels sont les compromis

Question

Je commence avec une base de données SQL Server. Donc, il semble que je devrais utiliser l'espace de noms de System.Data.SqlClient. Mais, il y a une chance que nous pourrions fermer notre base de données SqlServer et aller à MySql ou Oracle. Pour cette raison, je viens avec un ensemble de normes sur la façon dont nos applications .Net communiqueront avec la base de données, afin de faciliter la migration vers un système de base de données différente à l'avenir si nous devions le faire.

Voici donc les normes:

1. Utilisez un ORM si possible (par exemple NHibernate) (Non LINQ car il ne soutient SqlServer, mais qu'en est- cadre de l'entité et son soutien Oracle et MySql?)
2. Si ORM est une sur-kill, puis utilisez paramétrées requêtes SQL.
3. Utiliser des procédures stockées pour une longue course ou actions complexes doivent être effectuées sur la base de données.

Ce qui me amène à question principale à portée de main. Quel espace dois-je utiliser pour coder mon DAL?

Il me semble que le choix est entre System.Data.ODBC et System.Data.OleDB:

• Quels sont les compromis?
• est un préféré sur l'autre?
• Quelles sont vos réflexions sur les 3 premières normes?

Answer 1

System.Data.SQLClient

connecte à SQL Server 2000 et plus tard seulement, mais vous obtiendrez des performances optimales lors de la connexion à ces bases de données.

System.Data.OledbClient

Se connecte à SQL 6.5

OLEDBClient vous donne la possibilité de se connecter à d'autres bases de données comme Oracle ou Access. Mais pour travailler avec SQL Server, vous obtiendrez de meilleures performances en utilisant SQLClient.

Remarque:. Pour la connexion à ORACLE, Microsoft a également OracleClient

System.Data.ODBCClient

Se connecte à des bases de données héritées uniquement, en utilisant les pilotes ODBC. (Par exemple MS Access 97.)

source originale

Answer 2

Vous voulez utiliser le pilote SQL Server. Je comprends ce que vous essayez de faire, mais la façon dont vous accompliriez soutenir plusieurs bases de données est en insérant une autre couche d'abstraction. Vous pouvez le faire de plusieurs façons. Mais vous mettez la base de données code spécifique au bord de la hiérarchie de classe. Par conséquent, chaque classe peut obtenir les avantages de la base de données des fonctionnalités spécifiques, mais les appels de niveau supérieur ne savent pas ou attention à ce que la base de données est utilisée en dessous. En ce qui ORM, je préfère LLBLGen , mais cela est juste ma préférence.

En outre, pour clarifier, LINQ est pas spécifique à SQL Server. C'est LINQ to SQL. LINQ est une technologie d'interrogation que vous pouvez utiliser dans LINQ to SQL à LINQ-entités, LINQ-à-objets, et même LLBLGen prend en charge LINQ.

Answer 3

Peu importe si vous utilisez SQLClient ou Odbc pour l'instant, si vous utilisez des procédures stockées ou d'autres caractéristiques spécifiques à la base de données, vous devrez réécrire les si vous changez les moteurs de base de données.

Answer 4

Je venais d'utiliser SqlClient et re-écriture / re-générer le DAL si elle a changé.

À moins que vous allez mettre en œuvre et tester sur plusieurs plates-formes en ce moment, je ne suis pas sûr l'effort supplémentaire est en ce moment une grosse affaire ou pas moins que l'effort de refaire le DAL, et le fait que vous avez a obtenu un DAL tout signifie que vous avez tout en un seul endroit pour un changement plus tard de toute façon.

Answer 5

Si vous avez une petite idée que vous allez les bases de données swapping (ou le soutien backends multiples), puis un ORM est le chemin à parcourir. Sinon, vous aurez encore à factoriser / réécrire beaucoup de votre DAL afin de soutenir le changement. Si votre application est petite, il ne sera pas mauvais, mais rien de substantiel et vous serez mal.

Answer 6

Vous trouverez que l'utilisation de SQL Server SqlClient est beaucoup plus rapide et plus facile à développer avec de OleDB et ODBC - à moins qu'il est extrêmement probable que vous aurez besoin de prendre en charge plusieurs plates-formes, vous constaterez que les avantages l'emportent sur les risques que vous allez besoin de réécrire votre DAL.

En outre, en utilisant OleDB / ODBC est seulement 1 façon de maintenir l'indépendance de la plate-forme - vous trouverez peut-être plus efficace d'avoir plusieurs implémentations de votre DAL, chacun utilisant un natif de client à la plate-forme utilisée

.

Answer 7

Je l'ai entendu dire que si c'est un élément clé, vous ne devriez pas trop vous inquiéter de maintenir l'indépendance de la plate-forme. Cela dit,

SQLClient vous donnera un accès natif et devrait être plus performant (il ne doit pas faire des abstractions / traductions).

La seule chose que vous devez changer pour obtenir OLEDB travail vs ODBC est votre chaîne de connexion. OLEDB a un peu plus d'intelligence côté client il offre de meilleures performances.