Discussion :

[Barnabul]

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 ?

[Mat.M]

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.

[Barnabul]

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.

[Mat.M]

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

[escartefigue]

@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.

[Mat.M]

ok en tout cas merci pour le doc pdf qui est très intéressant

[Barnabul]

Merci beaucoup,
J'aime beaucoup les articles de Frédéric Brouard, il maitrise bien son sujet .

[SQLpro]

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 +

[Mat.M]

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.

[Barnabul]

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 ...

[Mat.M]

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.

[Barnabul]

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.

[tatayo]

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.

[KyoshiroKensei]

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...

[al1_24]

[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]

[tatayo]

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.

[Barnabul]

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...

Tout à fait. J'ai aussi eu droit au discours comme quoi les procédures stockées ça ramait, J'ai posé la question à 1 euro, " vous savez s'ils utilisent des curseurs ?" ; Réponse ; "Ben oui pourquoi ?".
Et les procédures stockées sont longues ? ... Plusieurs milliers de lignes....
La encore, lourdeur...
Effectivement, on peut prendre n'importe quel langage, si c'est écrit avec les pieds, c'est sûr que ça marchera pas...
Beaucoup de programmeurs ne comprennent pas que les bases de données, c'est un vrai métier. Il faut savoir les créer, les alimenter, et surtout savoir écrire des requêtes performantes, et ne pas adapter bêtement des pages entières de code rempli de structures conditionnelles; le SQL demande de repenser entièrement la façon de traiter l'info.

[Barnabul]

[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]

C'est gentil, ne t’inquiètes pas. Ça ne concerne pas directement le sujet, mais effectivement, ça fait longtemps que j'ai appris à rédiger des mails récapitulatifs, copie certaines personnes, après des instructions orales (jamais vu un cahier des charges en 20 ans, beaucoup trop dangereux ). Il y a effectivement en entreprise 2 types de collègues, ceux à qui tu peux faire confiance et avec qui tu peux échanger oralement et les petits chefs qui se gardent bien d'écrire quoi que ce soit et sont les premiers à te tomber dessus pour un truc qu'ils t'ont demandé de faire et qui s’avère être une énorme connerie ("mais enfin, tu te souviens pas ? On avait dit de faire comme ça ?", ou qui te mettent sur le dos leurs propres conneries.
Ce genre de personne il y en a hélas dans toutes les boîtes, et on pourrait écrire un bouquin dessus.
Donc t’inquiètes pas, je connais .
En même temps ce genre de personnes ne trompent qu'eux mêmes, les N+1 après avoir entendu leurs mêmes excuses ou arguments foireux pendant des mois finissent en général par comprendre à qui ils ont affaire.

[Barnabul]

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.

Il est très courant hélas que l'on dénigre ce que l'on ne connait pas. Une personne intelligente, ou simplement honnête sait revoir ses positions, se remettre en question. Mais la peur de passer pour un con ou une fierté mal placée est souvent la plus forte.
Après ça, on met les bêtises sous le tapis et on refile discrètement la patate chaude...

[Barnabul]

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.

Sans contrainte d’intégrité ou de clé étrangère, la BDD est condamnée à plus ou moins long terme à partir à la benne hélas. Sans squelette, ça peut pas tenir debout.
Vous avez pas fini de faire la chasse aux doublons ou "aux trucs qui déconnent".
Condoléances (snif)