Différence de vitesse entre OLE DB natif et ADO.NET

Question

Je cherche des suggestions ainsi que des repères ou des observations que les gens ont. Nous cherchons à réécrire notre couche d'accès aux données et essayons de choisir entre OLEDB ou ADO.NET C++ natif pour la connexion aux bases de données. Actuellement, nous ciblons spécifiquement Oracle, ce qui signifie que nous utiliserions le fournisseur Oracle OLE DB et ODP.NET.

Exigences: 1. Toutes les applications seront en code managé, donc l'utilisation de C++ OLEDB natif nécessitera C++/CLI pour fonctionner (pas de manière PInvoke à ralentir). 2. L'application doit fonctionner avec plusieurs bases de données à l'avenir, ciblant actuellement spécifiquement Oracle.

Question: 1. Serait-il plus performant d'utiliser ADO.NET pour accomplir ceci ou utiliser C++ OLE DB natif enveloppé dans une interface C++ managée pour l'accès au code managé?

Toutes les idées, ou de l'aide ou des lieux pour regarder sur le web seraient grandement appréciés.

Answer 1

Je ne pense pas qu'il soit possible de donner une réponse unique qui est généralement applicable dans cette situation étant donné que vous voulez une solution générale pour plus que Oracle. Le problème est que le fournisseur .NET d'un fournisseur peut être plus rapide que son fournisseur OLE DB et vice versa pour un autre fournisseur. L'architecture de ces deux technologies d'accès aux données est sensiblement différente. Mon intuition est que les différences de vitesse ne seraient pas si grandes, bien que. Comme il semble que vous mettiez votre propre couche d'accès aux données au-dessus de OLE DB, il est difficile de comparer directement jusqu'à ce que vous l'écriviez. Mais en général, toute déclaration de modification de données (par exemple, UPDATE mytable set ...) ne sera probablement pas très différente dans les deux cas. Avec les deux technologies, vous spécifiez les données de paramètres, le cas échéant, puis envoyez la commande au serveur. La majeure partie du coût sera probablement la latence du réseau et les temps d'exécution du serveur. La plus grande différence entrerait probablement en jeu lors de la lecture des ensembles de données.

Lire les données va être le facteur qui pourrait montrer une différence de vitesse. En fonction de ce que vous planifiez, vous pouvez lire les données à un niveau bas. Par exemple, avec OLE DB, vous pouvez appeler IRowset :: GetNextRows. Avec .NET, vous pourriez peut-être lire les ensembles de données via DbDataReader :: Read(). Je ne sais pas si c'est typique, mais dans le code sur lequel j'ai travaillé, la méthode OLE DB GetNextRows() était beaucoup plus complexe que l'implémentation .NET Read(). Je ne suis pas sûr que cela se traduise nécessairement par une exécution plus lente ... mais c'est possible. Selon moi, le meilleur choix serait d'utiliser ADO.NET. Comme c'est la technologie d'accès aux données actuelle de Microsoft, je soupçonne que les fournisseurs mettront à jour leur fournisseur .NET plus souvent que leur fournisseur OLE DB. Donc, s'il y a des problèmes de performances dans l'implémentation, le fournisseur .NET va probablement être corrigé alors que leur fournisseur OLE DB peut ne pas être corrigé aussi rapidement (ou pas du tout). En outre, vous bénéficiez d'une plus grande flexibilité avec le fournisseur .NET si vous en avez besoin (par exemple, framework d'entité). Si vous voulez cela avec OLE DB, vous aurez besoin d'utiliser le fournisseur .NET pour les fournisseurs OLE DB, qui est une autre couche au-dessus de OLE DB (en supposant que cela fonctionne même, ce que je ne sais pas).