IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement SQL Server Discussion :

Performance des API


Sujet :

Développement SQL Server

  1. #1
    Membre éprouvé
    Inscrit en
    Avril 2005
    Messages
    1 110
    Détails du profil
    Informations forums :
    Inscription : Avril 2005
    Messages : 1 110
    Points : 937
    Points
    937
    Par défaut Performance des API
    * Bonjour, *

    Je programme principalement en C/C++, sous Windows, avec des outils microsoft.
    Les DB sont sous SQL Server, microsoft aussi donc.
    Pour communiquer avec les DB de SQL Server j'utilise ODBC (des fonctions en C) et/ou MSADO (objets COM en C++).

    J'ai récemment comparé les performances des deux API et je me suis rendu compte que ODBC est bien plus performant, jusqu'à 2x en local (c-à-d programme et DB sur le même serveur).
    Je suis surpris d'une telle différence ! La surcouche MSADO serait-elle à ce point si lourde ?

    J'aimerais ainsi connaître vos expériences, quels langages utilisez-vous, quels API, les avez-vous comparé ?
    Merci

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 779
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 779
    Points : 52 754
    Points
    52 754
    Billets dans le blog
    5
    Par défaut
    Naticve connection (SQL NCLi) va plus vite encore dans certains cas....

    ADODB passe par des couches objets

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre éprouvé
    Inscrit en
    Avril 2005
    Messages
    1 110
    Détails du profil
    Informations forums :
    Inscription : Avril 2005
    Messages : 1 110
    Points : 937
    Points
    937
    Par défaut
    Bien, merci.

    Avec MSADO, que j'utilise le provider "native client" SQLNCLI11 ou l'habituel SQLOLEDB ne change rien aux performances:
    https://docs.microsoft.com/en-us/sql...-native-client

    Par contre, avec ODBC, l'usage du "native client" est encore plus performant !
    Et finalement, ODBC est plus "facile" à utiliser avec les types standards du C++ que MSADO.


    Personne n'a d'autre expérience à partager entre les différentes possibilités de communiquer avec SQL Server, avec en priorité les performances ?
    Remerci

Discussions similaires

  1. performances des virtual functions
    Par xxiemeciel dans le forum C++
    Réponses: 2
    Dernier message: 25/07/2005, 17h24
  2. [C#] Equivalence des API java en C# en ligne
    Par totoranky dans le forum Windows Forms
    Réponses: 6
    Dernier message: 15/02/2005, 01h16
  3. Comment appeler des API windows en C ?
    Par JuanLopez1966 dans le forum Windows
    Réponses: 6
    Dernier message: 22/12/2004, 10h34
  4. Performance des vertex array
    Par Mathieu.J dans le forum OpenGL
    Réponses: 13
    Dernier message: 25/06/2004, 10h47
  5. Utilisation des API MySQL // ADO ou BDE ? (sujet 2)
    Par rohstev dans le forum C++Builder
    Réponses: 8
    Dernier message: 07/11/2003, 10h50

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo