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 :

Procédures stockées VS APIs


Sujet :

Développement SQL Server

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    juin 2010
    Messages
    6
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : juin 2010
    Messages : 6
    Points : 15
    Points
    15
    Par défaut Procédures stockées VS APIs
    Bonjour,
    Une petite question me turlupine et je n'ai trouvé aucune réponse claire sur le réseau.
    La problématique est la suivante ;
    Ma boite développe une application en SAAS sous SQL SERVER.
    La logique de base qui a été appliquée est de ne mettre aucun métier dans la BDD.
    Du coup, exit les procédures stockées...
    IL y a cependant un truc qui me gène énormément. Je travaille sur l'ancienne mouture du logiciel en question, client lourd Windev + BDD SQL Server.
    J'ai notamment réécrit l'intégration dans le logiciel des fichiers de données qui nous sont envoyés sous forme de CSV.
    L'ancien traitement effectuait différents tests sur chaque rubrique.
    Pour un enregistrement de 50 rubriques et de 1000 lignes, on se retrouvait en multipliant à : 50 * 3 * 1000 = 150 000 requêtes.
    Donc pour chaque fichier traité, on envoyait 150 000 requêtes à la BDD pour savoir notamment si telle taille de rrubrique était correcte, telle référence existante etc ...
    Du coup j'ai réécrit ce truc immonde en procédure stockée. Je charge le fichier csv en BDD et j’exécute en tout et pour tout les 150 requêtes de contrôle qui examinent donc l'ensemble des 1000 enregistrements à chaque fois.
    Je suis passé de 40 minutes à 10 secondes.
    Le problème est que le nouveau logiciel qui ne jure que par les APIs écrit par l'autre équipe continue à exécuter gentiment 150 000 requêtes sous prétexte que les procédures stockées c'est de la merde dans un contexte SAAS.
    Leur fonctionnement en parallélisant les traitements a du les faire descendre à 10 minutes à tout casser.
    Je me demandais donc si je suis vraiment débile ou s 'il n'y a pas possibilité d'exploiter la puissance du SQL dans un contexte SAAS ?

  2. #2
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    8 102
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 8 102
    Points : 19 633
    Points
    19 633
    Par défaut
    bonsoir je ne suis pas certain de répondre correctement à la question mais c'est une évidence pour moi en appelant des procédures stockées le moteur du SGBDR sera plus performant pour traiter les requêtes.
    Cependant si vous voulez faire une requête ça peut se faire aussi avec du code donc si sur le projet pas de procédures stockées c'est que les API du projet ne sont pas assez performantes. Voir avec l'autre équipe ce qui bloque au niveau du "coeur de réacteur" du projet.
    Après si le DSI dit pas de procédures stockées l'autre raison à cela c'est que l'inconvénient des procédures stockées est d'être trop spécifique à un SGBDR en particulier.
    Bref du code pour SQL SERVER n'est pas portable sous Oracle.

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    juin 2010
    Messages
    6
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : juin 2010
    Messages : 6
    Points : 15
    Points
    15
    Par défaut
    Bonjour,
    Merci pour votre réponse.
    L'idée de base très souvent que j'entends est de solliciter SQL SERVER le moins possible. Ne s'en servir que pour faire du CRUD le plus homéopathique possible.
    Je trouve ça déjà très gênant car cela revient à mettre à disposition à un client une configuration qui ferait à peine l'affaire pour un ordinateur bureautique alors qu'on parle de comptabilité qui doit gérer des centaines de milliers d’enregistrements.
    L'intérêt principal de la procédure stockée pour moi, outre la performance est surtout de pouvoir gérer des transactions nickels.
    Mais bon, à ne pas vouloir solliciter le serveur sql et à déporter certains procédure métier afin d'alléger la sollicitation de SQL SERVER, en arguant l'effet goulet d'étranglement, je crains que l'on ne fait que déplacer le problème.
    Pour se retrouver ensuite sur des problématiques de sollicitation des canaux de communication ou de synchronisation des données.
    Je comprends l'argument de la non portabilité d'une procédure stockée, mais pour moi une procédure stockée bien écrite ne doit comporter pratiquement que des requêtes, la portabilité du coup devient anecdotique contrairement à l'éventualité où on voudrait changer de langage, car pourquoi parle t'on toujours de l'éventualité de changer de BDD et non de langage ou d'architecture ? Surtout quand on lit certains articles sur Oracle, ce n'est plus la Rolls que ça a pu être. Sql Server fait très bien le job. Et une version Express gratuite peut gérer des BDDs jusqu'à 10 gigas, en 20 ans, jamais vu de crash sous Sql Server ou de probléme de perf.
    Je vais réfléchir à tout ça, encore merci pour votre réponse.

  4. #4
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    8 102
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 8 102
    Points : 19 633
    Points
    19 633
    Par défaut
    salut Barnabul si le projet est réductible à du CRUD,c'est certain pas besoin de faire des requêtes complexes et imbriquées ,longues comme le bras,j'ai vu des projets en entreprise comme ça.
    Car dans lle projet il n'y a que des écrans CRUD il suffit de faire des Insert update et delete
    Car une grosse requête ça sollicite beaucoup le moteur du SGBDR.

    Ensuite pour ce qui est de la portabilité faut pas perdre de vue que la solution elle peut être destinée à se connecter sur AWS comme sur d'autres solutions Cloud comme sur MS-SQL server

  5. #5
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 968
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 968
    Points : 33 529
    Points
    33 529
    Billets dans le blog
    3
    Par défaut
    @Barnabul : je vous recommande, ainsi et surtout qu'à votre DSI, la lecture de cet article :

    http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

    @Mat.M : les requêtes mettant en œuvre de nombreuses tables et des requêtes corrélées ne sont pas obligatoirement les plus lentes, si les prédicats sont sargables et filtrants, tout va bien. Par contre, leur maintenance est parfois complexe, car la compréhension n'est pas toujours aisée.

  6. #6
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    8 102
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 8 102
    Points : 19 633
    Points
    19 633
    Par défaut
    ok en tout cas merci pour le doc pdf qui est très intéressant

  7. #7
    Membre à l'essai
    Profil pro
    Inscrit en
    juin 2010
    Messages
    6
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : juin 2010
    Messages : 6
    Points : 15
    Points
    15
    Par défaut
    Merci beaucoup,
    J'aime beaucoup les articles de Frédéric Brouard, il maitrise bien son sujet .

  8. #8
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 291
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : mai 2002
    Messages : 21 291
    Points : 50 994
    Points
    50 994
    Billets dans le blog
    1
    Par défaut
    Salut,

    oui en gros cet article que j'ai écrit il y a 10 ans est encore d'actualité malgré que les ORM et Frameworks se soient améliorés... En sus SQL Server est sans aucun doute le SGBDR le plus rapide du monde depuis près de 15 ans... Ce n'est même pas moi qui le dit, mais Glenn Paulley directeur technique chez l'éditeur concurrent Sybase (ancêtre de SQL Server) !
    https://techcommunity.microsoft.com/...ce/ba-p/383488

    Pour information dans le TPC E, MS SQL Sever est en tête depuis 2005 a tel point que presque aucun autre concurrent (Orcale, DB2...) n'a publié de benchmark...
    https://www.tpc.org/tpce/results/tpc...resulttype=all

    Alors quand on a une Ferrari, pourquoi ne pas la considérée comme un chariot ??? C'est un luxe d'imbécile friqué !
    Souvenons nous de Gainsbourg qui se servait de sa Rolls comme cendrier !

    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/ * * * * *

  9. #9
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    8 102
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 8 102
    Points : 19 633
    Points
    19 633
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Alors quand on a une Ferrari, pourquoi ne pas la considérée comme un chariot ??? C'est un luxe d'imbécile friqué !
    Souvenons nous de Gainsbourg qui se servait de sa Rolls comme cendrier !
    est-ce que vous travaillez dans le secteur puiblic ou privé ? Pour un projet commercial c'est une question de maitrise des coûts dans la chaîne de valeurs.
    Par exemple la refonte de Sncf Connect ça a coûté 20millions d'euros à ce que je sais il y a déjà 5 millions qui partent du budget pour mettre les données sur le Cloud.

  10. #10
    Membre à l'essai
    Profil pro
    Inscrit en
    juin 2010
    Messages
    6
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : juin 2010
    Messages : 6
    Points : 15
    Points
    15
    Par défaut
    Bonjour Mr Brouard,

    J'avais eu le plaisir de vous voir lors d'une formation optimisation sql server que vous aviez faite à ma boîte.
    C'était vraiment passionnant.
    Pour en revenir à SQL Server, je n'ai effectivement jamais réussi à faire comprendre à certains de mes collègues que le mieux placé pour travailler sur une base sql server, c'était sql server lui même.
    Ou alors il faut considérer que l'armée d'ingénieurs qui ont l'ont mis au point sont gravement débiles.
    Quel que soit le langage utilisé, aussi top moumoute soit-il, au final, on obtient invariablement une requête qui va s’exécuter sur le serveur SQL.
    Je n'ai jamais non plus réussi à leur fait comprendre qu'exploiter la puissance de sql server en travaillant de maniére ensembliste était infiniment plus puissant que de travailler en séquentiel en lançant autant de requêtes que l'on a d'enregistrements.
    Il y a hélas un vrai racisme, et un snobisme agressif qui fait que les langages un peu anciens sont nécessairement moins bons que le dernier à la mode.
    Au jour d'aujourd'hui, ils lancent 30 000 APIs pour traiter 30 000 enregistrements; ça tourne car pour le moment la toute nouvelle solution SAAS écrite en Go et Angular n'a qu'un client (le déploiement n'est toujours pas fini d'ailleurs, c'est bizarre y'a des trucs qui marchent mal).
    Je ne doute pas que d'ici quelques mois on va encore faire sauter un fusible ou deux dans cette nouvelle équipe, ce qui a été fait déjà plusieurs fois, pour au final vous demander un audit pour comprendre pourquoi ça marche si mal.
    Moi, je suis vieux, gros, barbu, j'aime le SQL, je suis plus à la page .
    Sinon quand je parlais de CRUD, je faisais référence à ce que vous expliquez dans votre article, à savoir que l'idée géniale de base est d 'utiliser la BDD uniquement pour du "stockage", en la sollicitant le moins possible et en déportant absolument tout le métier "ailleurs".
    Enfin bref ...

  11. #11
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    8 102
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 8 102
    Points : 19 633
    Points
    19 633
    Par défaut
    Citation Envoyé par Barnabul Voir le message
    Au jour d'aujourd'hui, ils lancent 30 000 APIs pour traiter 30 000 enregistrements;
    Enfin bref ...
    c'est un truc techniquement intenable le projet risque de vite partir au crash...
    vous pouvez pas solliciter le Directeur de projet et lui faire comprendre ?
    Des projets qui partent en vrille y'en a à la pelle dans le monde de l'IT.

  12. #12
    Membre à l'essai
    Profil pro
    Inscrit en
    juin 2010
    Messages
    6
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : juin 2010
    Messages : 6
    Points : 15
    Points
    15
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    c'est un truc techniquement intenable le projet risque de vite partir au crash...
    vous pouvez pas solliciter le Directeur de projet et lui faire comprendre ?
    Des projets qui partent en vrille y'en a à la pelle dans le monde de l'IT.
    je sais bien Mat, j'ai essayé plusieurs fois, mais on m'a clairement fait comprendre que je n'y connaissais rien, que "en SAAS on fait pas comme ça", etc ...
    D'autres collègues ont levé des anomalies, même topo. On a donc clairement décidé de laisser l'appli commencer à être déployée pour qu'ils comprennent enfin.
    Objectivement, je ne pense qu'il y en aura d'autres qui se feront remercier (j'étais un peu en boule, rien que d'y repenser); ils commenceront à revoir leur copie face à l'évidence que du coup ils seront obligés d'accepter, en production; et la réécriture se fera dans l'urgence et la douleur, comme souvent.
    Je ne suis pas sadique, mais au bout d'un moment quand on vous explique avec un sourire bienveillant que c'est pas comme ça qu'on fait, à force on lâche l'affaire.
    J'ai horreur de ce genre de choses, j'ai le sens du service et j’aime mon métier, mais il n'y a pas pire aveugle que celui qui ne veut pas voir.

  13. #13
    Expert éminent sénior
    Homme Profil pro
    Responsable Données
    Inscrit en
    janvier 2009
    Messages
    4 960
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : janvier 2009
    Messages : 4 960
    Points : 12 060
    Points
    12 060
    Par défaut
    Je compatis, je suis dans la même situation.
    Le pire est que quand j'ai été chargé du design de notre nouvelle base, dès que j'ai parlé d'identifiant auto, de contrainte d'intégrité... J'ai eu droit à une levée de boucliers.
    On m'a même répondu:" On sait que tu veux bien faire, mais fait au plus vite, tant pis on fera mieux plus tard".
    Mais quand on met en place le socle d'une application, "plus tard", c'est trop tard.

    Mais je n'ai pas lâché l'affaire, même si j'ai dû faire quelques concessions sur le reste du schéma (quelques tables obèses ), et ils commencent à admettre (très difficilement) que j'avais raison.

    Tatayo.

  14. #14
    Membre du Club
    Homme Profil pro
    Inscrit en
    juin 2011
    Messages
    80
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2011
    Messages : 80
    Points : 54
    Points
    54
    Par défaut
    A lire ce fil de discussion, je me sens du coup moins seul dans mon ptit monde de procédures stockées faites avec passion...

    Le lien PDF fournit par escartefigue se suffit à lui même pour comprendre la puissance des bases de données épaisses. Perso, je l'ai fourni à l'ensemble des membres de mon équipe il y a quelques temps. Quelques points de vue ont pu évoluer.

    Ensuite, si tu peux présente des tests réels entre la solution en ps et la solution actuelle. Une démonstration vaut mieux qu'un discours et le gens de mauvaise foi ou borné se retrouvent coincés .

    Un seul bémol concernant les ps: il faut des développeurs aguerris sur SQL, sinon il font un carnage. Certains font leur requêtes avec des curseurs un peu partout...

  15. #15
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Retraité
    Inscrit en
    mai 2002
    Messages
    9 009
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2002
    Messages : 9 009
    Points : 30 366
    Points
    30 366
    Par défaut
    [Hors sujet]@Barnabul, @tatayo,
    On ne vous a pas dit : "ça, c'est ce qu'on apprend à l'école. On ne fait pas ça dans la vraie vie." ?
    Et quand ça plante, ça fait très mal.
    C'est le moment d'avoir protégé ses arrières en ayant eu soin d'énoncer ses mises en garde par écrit, dans des mails.
    Et même là... [/Hors sujet]
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  16. #16
    Expert éminent sénior
    Homme Profil pro
    Responsable Données
    Inscrit en
    janvier 2009
    Messages
    4 960
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : janvier 2009
    Messages : 4 960
    Points : 12 060
    Points
    12 060
    Par défaut
    si seulement j'avais reçu ce genre de réponse. Même pas.
    Par exemple quand j'ai parlé d'identifiant auto:
    "Oui, mais non, j'aime pas trop, quand je veux lancer une requête pour faire de la maintenance, il faut faire des jointures...".
    Et hop, une vue qui va bien.
    Les triggers:
    Je voulais mettre en place des trigger sur des tables, ainsi par exemple quand une commande est créée/modifiée, une ligne est ajoutée dans une table de message, pour qu'elle soit traitées dans des flux d'export.
    "Heu non, je ne suis pas fan des triggers, je préfère quand le code est dans l'application".
    Résultat quand il a fallu traiter une table "non prévue" à l'avance, ma réponse n'a pas tardé:
    "Bha maintenant il faut chercher tous les traitements qui mettent à jour cette table, pour générer le message qui va bien, alors qu'un simple trigger aurait suffi, sans remettre en cause l'existant.".

    Maintenant j'ai des vues avec des triggers INSTEAD OF, ce qui arrange bien tout le monde.

    Mais je n'ai eu que des aveux "à demi-mots" sur le fait que j'avais raison.
    Et la personne en question avoue qu'il n'est ni développeur, ni DBA.

    Le plus fort est que je n'ai reçu aucune objection concernant les procédures stockées...

    Tatayo.

Discussions similaires

  1. passage d'un nom de table dans une procédure stockée
    Par thierry V dans le forum MS SQL Server
    Réponses: 7
    Dernier message: 26/07/2010, 17h48
  2. Procédure stocké:Insert et renvoie de la clé primair
    Par caramel dans le forum MS SQL Server
    Réponses: 4
    Dernier message: 17/04/2003, 10h34
  3. [Pervasive SQL ] procédure stockée
    Par magellan dans le forum Autres SGBD
    Réponses: 2
    Dernier message: 25/10/2002, 14h17
  4. Explication procédure stockée
    Par underworld dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 09/09/2002, 11h51
  5. [Comparatif] Procédures stockées, triggers, etc.
    Par MCZz dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 28/08/2002, 13h27

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