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

SQL Procédural MySQL Discussion :

Performances des procédures stockées


Sujet :

SQL Procédural MySQL

  1. #1
    Membre à l'essai
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2016
    Messages
    63
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2016
    Messages : 63
    Points : 16
    Points
    16
    Par défaut Performances des procédures stockées
    Bonjour,

    Étant un nouvel arrivant dans une entreprise je voulais savoir si les procédures stockées pouvait ralentir ou dégrader les performances d'un serveur JBOSS ?
    Mon collègue me dit qu'ils avaient surement de bonnes raisons de ne pas mettre de procédures stockées sur ce serveur ... si oui quelles seraient ces raisons? car je ne vois que des avantages sur ces procédures stockées sur le net.

    Il faut savoir que le serveur peut à tout moment faire de gros traitements, donc je ne sais pas si c'est pour cela qu'ils ne veulent pas de procédures stockées

    Merci pour vos avis et réponses !

    Bonne journée.

  2. #2
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 344
    Points : 18 919
    Points
    18 919
    Par défaut
    Salut smalt72.

    Votre pseudo a un rapport avec le whisky ? (Single malt whisky année 1972)

    Citation Envoyé par smalt72
    les performances d'un serveur JBOSS ?
    C'est quoi un serveur JBOSS ?

    Citation Envoyé par smalt72
    si oui quelles seraient ces raisons?
    Vous voulez dire la différence qu'il y a entre une requête et une procédure stockée ?

    Sans rentrer dans le détail, la requête doit subir en premier lieu une analyse syntaxique puis ensuite être interprété avant son exécution.
    A l'inverse la procédure stockée est comme qui dirait pré-compilée. Elle est donc plus rapide car elle ne subit pas la lourdeur de la requête.
    Et quand vous l'appelez, elle va directement s'exécuter car la phase de l'analyse et de l'interprétation aura déjà été faite.
    Cela dépend surtout comment elle est gérée dans les SGBD.

    Hormis cette phase, cela dépend de ce que vous faites dans la procédure stockée qui est en fait un programme.
    En règle général, il est déconseillé de faire des procédures stockées, des fonctions, des triggers car cela va alourdir les requêtes.
    C'est ce que l'on me disait quand je faisais du DB2 (Gros système IBM). Même des requêtes avec des jointures nous étaient interdites.

    Sur un mini ordinateur, genre Linux, le problème n'est le même car il est multicoeur multithreading.
    Donc le problème est d'abord matériel, puis ensuite dans la façon dont le SGBD va gérer les accès aux données.
    L'autre contrainte est le choix d'un bon SGBD. MySql n'est pas bon pour ce genre de chose.
    Le mieux est de choisir Microsoft SQL Server qui est plus performant !

    Quand vous avez un serveur de base de données, il est conseillé de faire en sorte que vos requêtes passent le moins de temps à s'exécuter.
    Donc à fortiori une procédure stockée qui va s'exécuter en parallèle et peut au pire bloquer vos requêtes, ou voire les ralentir.

    Sinon, ces procédures stockées vont vous servir à faire quoi ? De l'administration ? Ou des traitements ?

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  3. #3
    Membre à l'essai
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2016
    Messages
    63
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2016
    Messages : 63
    Points : 16
    Points
    16
    Par défaut
    tout d'abord non je ne connais pas ce whisky mais vu que monsieur a l'air connaisseur j'essayerais d'y jeter un coup d’œil

    Et bien en gros ces procédures stockées serviraient à savoir de quel projet un article fait parti, je m'explique :
    1 - si un article a un numéro de PN alors il fait parti d'un projet dont on peut trouver le nom grâce à la correspondance avec le PN, l’idéale serait de retourner une string avec le nom de tout les projets (exemple : "Projet1, Projet2, projet3.......")
    2 - si il n'a pas de PN correspondant alors il appartient à zéros projet et donc la chaine nulle est retournée.


    et oui c'est en MySQL.... du coup on va peut être tout faire dans le code ce sera peut être mieux non? ^^

    et de plus le serveur n'est pas très performant on m'a dit...

    JBOSS est un serveur pour les appli java en gros


    Merci de ta réponse grand connaisseur de whisky !

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    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 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    En règle général, il est déconseillé de faire des procédures stockées, des fonctions, des triggers car cela va alourdir les requêtes.

    Non, vous ne pouvez pas faire une règle générale de cette affirmation. Pour information c'est Sybase qui a inventé le concept de "Persitent Stored Module" en 1986 (normalisé peu après) avec l'apparition en premier des déclencheur suivi, l'année d'après avec les procédures. Et au départ elles était plus optimisée que les requêtes "ad hoc". Quand à la surcharge de la base je ne voit pas en quoi une chaine de caractères de quelques centaine d'octets alourdirait considérablement le stockage des données. Tout ceci sont des affirmations de vieux c... qui hélas se voit encore parfois chez les clients... (j'ai pas dit que le vieux c... c'était vous !!!!)
    Je dirais même qu'aujourd'hui les procédures stockées utilisées à bon escient, permettent des performances inatteignables par toute autre approche.
    C'est ce que l'on me disait quand je faisais du DB2 (Gros système IBM). Même des requêtes avec des jointures nous étaient interdites.

    Sur un mini ordinateur, genre Linux, le problème n'est le même car il est multicoeur multithreading.
    Donc le problème est d'abord matériel, puis ensuite dans la façon dont le SGBD va gérer les accès aux données.
    L'autre contrainte est le choix d'un bon SGBD. MySql n'est pas bon pour ce genre de chose.
    Là effectivement il y a encore du boulot en perspective...
    Le mieux est de choisir Microsoft SQL Server qui est plus performant !

    Quand vous avez un serveur de base de données, il est conseillé de faire en sorte que vos requêtes passent le moins de temps à s'exécuter.
    Donc à fortiori une procédure stockée qui va s'exécuter en parallèle et peut au pire bloquer vos requêtes, ou voire les ralentir.

    Sinon, ces procédures stockées vont vous servir à faire quoi ? De l'administration ? Ou des traitements ?

    @+
    Voilà une bonne question... Et puis cela dépend du modèle. Si modélisé correctement (donc normalisé) l'apport des proc stocke est hyper performant. Si table obèse, il ne servira pas à grand chose...

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

  5. #5
    Membre à l'essai
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2016
    Messages
    63
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2016
    Messages : 63
    Points : 16
    Points
    16
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Je dirais même qu'aujourd'hui les procédures stockées utilisées à bon escient, permettent des performances inatteignables par toute autre approche.
    en gros les procédures stockées sont maintenant normalement jugées très performantes? (même sous MySQL?)

    Citation Envoyé par SQLpro Voir le message
    Quand à la surcharge de la base je ne voit pas en quoi une chaine de caractères de quelques centaine d'octets alourdirait considérablement le stockage des données.
    je ne stocke même pas cette chaine ... je l'envoie juste à mon client ensuite
    c'est juste que je ne veux pas que le serveur soit considérablement ralentit par cette procédure...

    Citation Envoyé par SQLpro Voir le message
    Voilà une bonne question... Et puis cela dépend du modèle. Si modélisé correctement (donc normalisé) l'apport des proc stocke est hyper performant. Si table obèse, il ne servira pas à grand chose...
    la procédure est donc a faire sur des tables "petites" du coup si j'ai bien compris?

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    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 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Les procédures stockées permettent d'encapsuler une logique complexe, généralement transactionnées, permettant d'éviter de nombreux aller et retour entre le serveur et le client. D’où des gains de temps de traitement considérables, mais aussi une moindre durée des blocages liés au verrous transactionnel et donc d'absorber une meilleure concurrence.

    Un exemple simple : pour faire un virement d'un compte courant à un compte épargne, l'un étant dans la table T_COMPTE_BANCAIRE l'autre dans la table T_COMPTE_EPARGNE, il est nécessaire d'effectuer 2 mises à jours :
    1) le retrait de la somme du compte bancaire (UPDATE T_COMPTE_BANCAIRE SET SOLDE = SOLDE - montant WHERE CLIENT = 'dupont')
    2) l'ajoute de la même somme au compte épargne, si la première requête a bien fonctionnée (UPDATE T_COMPTE_EPARGNESET SOLDE = SOLDE + montant WHERE CLIENT = 'dupont')
    Le tout devant donc être encapsulé dans une transaction.
    Symboliquement, avec du SQL normalisé ceci se traduit dans la séquence suivante :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    BEGIN WORK
    UPDATE T_COMPTE_BANCAIRE SET SOLDE = SOLDE - montant WHERE CLIENT = 'dupont';
    UPDATE T_COMPTE_EPARGNESET SOLDE = SOLDE + montant WHERE CLIENT = 'dupont';
    COMMIT WORK;
    SIGNAL
        ROLLBACK;
    Si vous effectué ce traitement dans du code client il vous faudra enchainer au moins 4 instructions :
    • Démarrage de la transaction
    • Envoi du premier UPDATE et attente de la réponse. Si tout s'est bien passer continuer, sinon annuler
    • Envoi du second UPDATE et attente de la réponse. Si tout s'est bien passer continuer, sinon annuler
    • Valider la transaction

    Ceci va donc générer 4 aller et retour contre un seul pour la procédures stockées.
    Sachant qu'une instruction SQL c'est généralement moins de 0.1 ms
    Qu'un aller et retour réseau dans une bonne infrastructure c'est en général 3 ms

    Avec la proc stock, le temps mis sera de :
    • 3 ms un aller et retour + 0.4 ms (les 4 instruction SQL)


    Avec le code client, le temps mis sera de :
    • 12 ms des 4 aller et retours + 0.4 ms (instructions SQL unitaires).

    Bilan des opérations :
    Temps de réponse : 12.4 contre 3.4, soit 3,6 fois plus rapide par procédure stockée....
    Durée du verrouillage : à.4 secondes dans la cas de la procédure stockée contre 6.3 secondes pour le code client, soit 16 fois plus de concurrence potentielle !

    CQFD.

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

  7. #7
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 344
    Points : 18 919
    Points
    18 919
    Par défaut
    Salut à tous.

    Citation Envoyé par SQLPRO
    Quand à la surcharge de la base je ne voit pas en quoi une chaine de caractères de quelques centaine d'octets alourdirait considérablement le stockage des données.
    Je ne parle pas du stockage de la procédure stockée mais de son temps d'exécution, c'est-à-dire de sa performance !
    Ou alors exprimez-vous mieux car on risque d'avoir des quiproquos.

    Citation Envoyé par SQLPRO
    Tout ceci sont des affirmations de vieux c... qui hélas se voit encore parfois chez les clients...
    Ce qui prouve qu'à une époque, cette affirmation était vraie. Sinon comment expliquer que cette affirmation à la vie dure ?

    D'ailleurs en MySql, il suffit de faire le test entre une simple requête un peu coûteuse en temps d'exécution et là même encapsulée dans une procédure stockée.
    Et que constatons ? Que la procédure stockée sera bien plus longue à l'exécution que la simple requête.
    Donc non, ce ne sont pas des affabulations de vieux c..., mais bien une réalité qui existe sous MySql.

    Citation Envoyé par SQLPRO
    Je dirais même qu'aujourd'hui les procédures stockées utilisées à bon escient, permettent des performances inatteignables par toute autre approche.
    Franchement, je ne suis pas convaincu par votre affirmation !
    Et vu que cela dépend aussi de l'organisation de vos données au sein de la base de données, de la solution que vous utilisez, voire aussi de la surcharge de votre machine, fait qu'au final il y a trop de paramètres qui peuvent influencer la comparaison en performance entre requête et procédure stockée.

    Rien que le fait de faire un balayage d'une table avec un curseur rend votre procédure stockée désastreuse en terme de performance.
    Nous avons déjà eu une conversation à ce sujet ! Auriez-vous changé d'avis ?

    Citation Envoyé par SQLPRO
    Là effectivement il y a encore du boulot en perspective...
    C'est ce que l'on me disait, fin des années 1980 quand j'ai commencé à pratiquer le DB2 en tant que développeur, bien avant de devenir DBA.
    Et sur ce genre de machine, il n'y a pas vingt personnes qui accèdent aux bases de données, mais plusieurs centaines de milliers de personnes dans le monde.
    Ce n'est pas un simple mini-ordinateur où Microsoft SQL Server ou encore MySql est installé, mais un gros système IBM z/os, TSO ISPF, dont les utilisateurs accèdent partout dans le monde.
    Et le tout avec des temps de réponses de moins de 1 seconde !
    Donc non, on ne peut pas se permettre de perdre du temps, juste pour faciliter la vie des utilisateurs.

    L'approche est complètement différente dans le monde web, sur des machines où le chemin critique des performances n'est pas très cruciale.

    Revenons à MySql, où justement cette approche n'est pas appropriée.
    A moins d'avoir un réel besoin en terme de procédure stockée, il n'est pas recommander de l'utiliser sous MySql.

    Citation Envoyé par SQLPRO
    Voilà une bonne question...
    Ce n'est pas une bonne question, c'est juste une simple constatation que l'on peut faire en terme de performances quand un SGBD est bien écrit.

    Citation Envoyé par SQLPRO
    Si modélisé correctement (donc normalisé) l'apport des proc stocke est hyper performant. Si table obèse, il ne servira pas à grand chose...
    A bon, on fait des procédures stockées sur des tables contenant très peu de lignes ???
    Donc vous reconnaissez que sur de très grosses volumétries, la procédure stockée n'est pas adaptée.

    Citation Envoyé par smalt72
    en gros les procédures stockées sont maintenant normalement jugées très performantes? (même sous MySQL?)
    Surtout en MySql, la procédure stockée n'est pas performante. SQLPRO parlait de Microsoft SQL Server, et encore, car cela dépend de ce que vous faites avec.
    Je vous déconseille d'utiliser les procédures stockées, mais si vous ne pouvez pas faire autrement, lancez-vous.

    Citation Envoyé par smalt72
    la procédure est donc a faire sur des tables "petites" du coup si j'ai bien compris?
    Petite ou grosse table, cela n'a aucune importance car c'est dans la façon de traiter les lignes au sein d'un curseur que l'on perd en terme de performance.
    Si vous avez la possibilité de le faire par une requête, le résultat sera bien meilleur qu'avec une procédure stockée.

    Citation Envoyé par SQLPRO
    Les procédures stockées permettent d'encapsuler une logique complexe, généralement transactionnées, permettant d'éviter de nombreux aller et retour entre le serveur et le client.
    Oui, vous avez raison, j'ai oublié de parler de l'économie de temps que l'on fait au niveau des aller-retour entre le serveur et le client.
    Mais ce n'est pas le critère que l'on doit retenir pour faire une procédure stockée.

    Si le traitement est complexe, voire à l'identique d'un traitement de masse, il se peut que la procédure stockée réponde à ce genre de problème.
    Mais encore une fois, cela dépend de ce que vous voulez faire.

    En DB2, pour des traitements de masse, on déchargeait la table, que l'on traitait en cobol puis on la rechargeait ensuite.
    Ce genre de pratique était plus performante que de faire une procédure stockée.
    Bon, cela remonte à plus de vingt ans déjà, et j'espère que depuis, on a fait d'énorme progrès en DB2.
    A l'époque où j'ai fait ce genre de traitement, j'étais dans la version 5 de DB2.
    Ce choix m'a été imposé par des gens qui à l'époque était plus compétent que moi.

    Citation Envoyé par SQLPRO
    Temps de réponse : 12.4 contre 3.4, soit 3,6 fois plus rapide par procédure stockée....
    Même si ce que vous dites est vrai, ce n'est pas significatif. Votre performance est de l'ordre de la milliseconde, donc négligeable.
    Et puis, quel est l'intérêt de faire une procédure stockée en mettant en dure le nom du client ("WHERE CLIENT = 'dupont'".

    Tant que vous faites de l'inter-activité entre le client et le serveur et que la performance est inférieur à la seconde, le choix de la requête ou de la procédure stockée est négligeable.
    Si vous faites un traitement de masse sur d'énorme volumétrie, la performance entre la requête et la procédure stockée n'est plus du tout négligeable.
    Il sera même préférable de faire des requêtes qui seront plus performantes, à l'inverse de la procédure stockée avec un curseur qui sera nécessairement plus coûteuse.

    Citation Envoyé par SQLPRO
    CQFD.
    Et bien non, vous ne pouvez pas généraliser en partant d'un cas particulier pour affirmer que la procédure stockée est meilleure que la requête.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  8. #8
    Membre à l'essai
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2016
    Messages
    63
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2016
    Messages : 63
    Points : 16
    Points
    16
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Je ne parle pas du stockage de la procédure stockée mais de son temps d'exécution, c'est-à-dire de sa performance !
    Je parlais moi aussi de la performance de la procédure sur le serveur ...

    Pour résumer ... MySQL c'est un peu la voiture a pédale quoi?

  9. #9
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 344
    Points : 18 919
    Points
    18 919
    Par défaut
    Salut smalt72.

    SQLPRO parlait de Microsoft SQL Server et ce SGBDR est bien plus performant que MySql.
    Tandis que je parlais de MySql et je peux vous assurer que sur de la grosse volumétrie, MySql est lent, que dis-je un escargot.

    Je vous conseille vivement de choisir Microsoft SQL Server qui est bien plus performant à l'inverse de MySql.
    Si votre critère concerne les performances, MySql n'est pas adapté à ce genre de critère.

    Citation Envoyé par smalt72
    Pour résumer ... MySQL c'est un peu la voiture a pédale quoi?
    MySql est destiné à de petites base de données, que l'on développe en tant qu'amateur.
    Si vous êtes un professionnel, orientez-vous vers un SGBDR professionnel comme Microsoft SQL Server.

    MySql est très bien pour apprendre, c'est-à-dire se faire la main à l'école.
    Ce n'est pas parce qu'il est gratuit à l'installation, qu'il ne va pas au final coûter plus cher qu'un SGBDR avec licence.
    Les temps d'exécutions seront plus longues, et vous serez obliger d'investir dans le matériel pour récupérer un peu de performance.
    Jusqu'au jour où vous vous sentirez à l'étroit et vous serez alors obligé de basculer vers un vrai SGBDR avec licence.
    Pourquoi ? Car MySql ne gère pas très bien la sécurité, les reprises en cas de plantage, les backup, les performances ...

    Pour revenir aux procédures stockées, ce n'est pas quelque chose d'indispensable pour gérer vos bases de données.
    Pendant plusieurs années, je n'en ai pas fait car sous DB2, cela nous était interdit.
    Tout ce que vous pouvez faire avec une procédure stockée, vous pouvez le faire au niveau applicatif. La seule différence sera la performance.

    Mais comme vous êtes flou dans votre besoin, il est difficile de répondre avec exactitude sur des questions de performances.
    Si vous faites des traitements de masse, la procédure stockée n'est pas adapté à la performance.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  10. #10
    Membre à l'essai
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2016
    Messages
    63
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2016
    Messages : 63
    Points : 16
    Points
    16
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Si vous êtes un professionnel, orientez-vous vers un SGBDR professionnel comme Microsoft SQL Server.
    si seulement c'etait possible.... l'application est déja mise en place.... :'(


    Citation Envoyé par Artemus24 Voir le message
    Tout ce que vous pouvez faire avec une procédure stockée, vous pouvez le faire au niveau applicatif. La seule différence sera la performance.
    oui c'est sur je savais deja mais je voulais juste savoir si sur un serveur de basse qualité il fallait plutot recupérer les données en brut ou juste ce dont on a besoin....

    Citation Envoyé par Artemus24 Voir le message
    Mais comme vous êtes flou dans votre besoin, il est difficile de répondre avec exactitude sur des questions de performances.
    Si vous faites des traitements de masse, la procédure stockée n'est pas adapté à la performance.
    vous inquiètez pas merci à vous deux vous avez largement répondu à ma question et bien plus encore

  11. #11
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 344
    Points : 18 919
    Points
    18 919
    Par défaut
    Salut smalt72.

    Citation Envoyé par smalt72
    si seulement c'etait possible...
    C'est une erreur classique de négliger le choix du SGBD.
    Au démarrage, vous êtes trois clampins à travailler avec une petite volumétrie et tout se passe normalement.
    Vous passez à quelques centaines d'utilisateurs, et la volumétrie a explosée, et le pauvre MySql ne suit plus du tout.
    Et c'est là que vous demandez de l'aide pour l'optimisation.
    Et dans l'urgence, vous basculez vers un SGBDR professionnel adapté à ce que vous faites.
    C'est pas très professionnel de travailler ainsi, c'est-à-dire sans faire une étude des besoins.

    Citation Envoyé par smalt72
    je voulais juste savoir si sur un serveur de basse qualité il fallait plutôt récupérer les données en brut ou juste ce dont on a besoin....
    Normalement, votre serveur MySql vous sert à extraire des données et non à faire de la présentation de ces mêmes données.
    Je ne sais pas pourquoi, certains utilisateurs s’entêtent à vouloir tout faire avec MySql et ensuite, ils viennent râler que la performance n'est pas au rendez-vous.

    Ma réponse sera mitigée, c'est-à-dire qu'une partie sera faite avec MySql et l'autre partie sera faite avec php.

    Sous MySql les dates se présentent sous le format "YYYY-MM-DD". Et à l'affichage, donc sur votre page web, vous désirez les présentez sous le format "DD/MM/YYYY".
    Le mieux est de faire cette conversion en php car c'est de la présentation et cela n'a aucun intérêt, sauf à perdre du temps, à le faire sous MySql.

    Vous extrayez des lignes et sur chaque ligne ayant le même critère, vous avez disons une valeur.
    Vous désirez mettre ces valeurs sur la même ligne. Comme c'est de la présentation, ce n'est pas le rôle de mysql de faire cela, même si la fonction "group_concat()" permet de le faire.
    Alors qu'en php, il suffit de concaténer vos valeurs, et sur la rupture de séquence sur votre critère, vous affichez le résultat.

    En fait, je pense que la plupart du temps, les développeurs n'ont pas les connaissances requises pour mener à bien leur projet.
    Ils n'ont ni la connaissance suffisante en informatique et encore moins la connaissance du sujet de leur projet.

    Citation Envoyé par smalt72
    vous inquiétez pas merci à vous deux vous avez largement répondu à ma question et bien plus encore
    Il ne faut pas croire qu'il est interdit de faire des procédures stockées.
    Disons que dans la plupart des cas, il n'est pas nécessaire d'utiliser ces outils (trigger, function, stored procedure).
    Le principal problème est de modéliser correctement votre base de données afin de répondre à vos attentes.
    Comme cette partie est souvent négligée, avec le choix du SGBD, il n'est pas rare de voir des usines à gaz se créer !

    Même si sur certains points SQLPRO et moi-même nous divergeons, nous nous retrouvons sur la nécessite de faire une étude au préalable à tout projet avant de faire du développement. Pourquoi ?
    Pour justement ne pas se poser des questions fondamentales lors du développement.
    Normalement le travail du DBA en amont est de répondre à la faisabilité du projet, coté base de données.
    Celle de l'analyste est de répondre à la faisabilité du projet, coté développement.
    Un dossier doit accompagner le développeur sur la structure des tables, les règles de gestions et sur les requêtes ainsi que leur optimisation.
    C'est dans ce dossier que la nécessité d'une procédure stockée sera soulevée, solutionnée ou rejetée. Idem pour les trigger, et les functions

    Normalement les questions que vous vous posez n'ont pas lieu d'être si le travail en amont a été fait !

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  12. #12
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    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 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    1) je ne parlais pas de SQL Server au sujet de procédures stokes mais bien de MySQL. C'est vous qui me faite dire ce que je n'ai pas dit.
    Soit vous êtes à ce point incapable de lire ce qui est écrit, alors offre-vous des lunettes
    Soit vous êtes de mauvaise fois et là c'est pire !

    2) avez vous fait votre test entre la PS et le code SQL avec un client distant et 2 requêtes avec condition d'enchainement ? J'en doute fortement... Donc test biaisé pour pouvoir raconter n'importe quoi !

    ...

    Citation Envoyé par Artemus24 Voir le message
    Disons que dans la plupart des cas, il n'est pas nécessaire d'utiliser ces outils (trigger, function, stored procedure).
    J'ai donné l'exact exemple inverse.

    De plus vous ne pouvez pas vous passer d'un certain nombre d'élément du PSM, notamment des déclencheurs cars ils permettent d'élaborer des contraintes complexes qu'aucun code client n'est capable de reproduire sauf à n'avoir jamais qu'un seul utilisateur simultané.

    Pour le reste je laisse les autres vous agonir de -1 auxquels vous semblez être bien abonné !

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

  13. #13
    Membre extrêmement actif Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    Octobre 2007
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Singapour

    Informations professionnelles :
    Activité : Ingénieur recherche et développement

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 676
    Points : 2 010
    Points
    2 010
    Par défaut
    Citation Envoyé par smalt72 Voir le message
    Bonjour,

    Étant un nouvel arrivant dans une entreprise je voulais savoir si les procédures stockées pouvait ralentir ou dégrader les performances d'un serveur JBOSS ?
    Mon collègue me dit qu'ils avaient surement de bonnes raisons de ne pas mettre de procédures stockées sur ce serveur ... si oui quelles seraient ces raisons? car je ne vois que des avantages sur ces procédures stockées sur le net.

    Il faut savoir que le serveur peut à tout moment faire de gros traitements, donc je ne sais pas si c'est pour cela qu'ils ne veulent pas de procédures stockées

    Merci pour vos avis et réponses !

    Bonne journée.
    Bonsoir,

    En général, les partisans du monde J2EE n'aiment pas les procédures stockées parce qu'ils considèrent 1/ que leur couche d'abstraction fait tout 2/ qu'il est plus simple de faire de la montée en charge en ajoutant des serveurs d'application que des serveurs de base de données.
    Pour le point n°1, je pense qu'on en revient un peu, même si personne ne va aujourd'hui mettre les ORM à la poubelle
    Pour le point n°2, ils n'ont pas tout à fait tord, mais évidement cet argument sert surtout à vendre des licences Jboss plutôt que des licences SQL Server . Ce qui est de bon goût.

    On peut marier le meilleur des deux monde en utilisant les @NamedNativeQueries d'hibernate par exemple. Avec en contrepartie une plus forte complexité et des coûts de maintenance plus élevés : la mise à jour du schéma d'une table ne se reflètera dans les procédures stockées avant de les avoir recrées. Et quand on commence à avoir des procédures stockées appelées en cascade, c'est souvent le début de la fin, ne serait-ce que parce les règles de vérifications syntaxiques sont beaucoup plus lâches en SQL (ou en T-SQL qu'en Java).

    Et par expérience, vouloir gagner quelques millisecondes de traitement est souvent du domaine de l'optimisation prématurée, alors qu'il faut en général se concentrer sur l'optimisation et la réécritures de certaines requêtes très lourdes.
    Ce qui implique que l'angle d'approche dépend aussi de la volumétrie.
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  14. #14
    Membre confirmé Avatar de isabelle.letrong
    Femme Profil pro
    Conseil - Consultante en systèmes d'information
    Inscrit en
    Juillet 2010
    Messages
    109
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Conseil - Consultante en systèmes d'information
    Secteur : Conseil

    Informations forums :
    Inscription : Juillet 2010
    Messages : 109
    Points : 487
    Points
    487
    Par défaut
    Citation Envoyé par smalt72 Voir le message
    Bonjour,

    Étant un nouvel arrivant dans une entreprise je voulais savoir si les procédures stockées pouvait ralentir ou dégrader les performances d'un serveur JBOSS ?
    Mon collègue me dit qu'ils avaient surement de bonnes raisons de ne pas mettre de procédures stockées sur ce serveur ... si oui quelles seraient ces raisons? car je ne vois que des avantages sur ces procédures stockées sur le net.

    Il faut savoir que le serveur peut à tout moment faire de gros traitements, donc je ne sais pas si c'est pour cela qu'ils ne veulent pas de procédures stockées

    Merci pour vos avis et réponses !

    Bonne journée.
    Bonsoir,

    Étonnante discussion de salon.....
    Beaucoup d'affirmations péremptoires de personnes, apparemment très galonnées, mais qui n'ont à l'évidence pas une expérience éprouvée de mis en oeuvre des procédures stockées, fonctions et autres triggers dans l'environnement MySQL .

    Pour ma part, j'ai développé et mis en production un moteur de paye, conforme à la législation française (2016 !), entièrement sous MySQL : 50 000 lignes rien qu'en procédures, fonctions et triggers . Ceux qui connaissent un peu la législation sur le sujet, qui est en perpétuel mouvement et le fruit de l'imagination très très créative et compliquée de nos législateurs, comprennent que ce code se doit d'être maintenable ! J'ai fait le choix de centraliser TOUTES les règles de gestion et de production de la paye DANS MySQL, de confier aux développeurs Java et PHP uniquement l'interface utilisateurs et voyez-vous, ce n'est pas l'apocalypse annoncée...

    Ce qui a dicté ce choix, n'est pas tant une question de performances intrinsèques, mais plutôt de capacité à centraliser les règles et maîtriser le modèle. Le modèle de donnée sous-jacent d'un moteur de paye est complexe : on y gère des données à valeurs temporelles, des taux variables qui peuvent s'appliquer sur des données élémentaires, composites, agrégés, cumulées... mais ce modèle doit bien sur aussi être conçu pour supporter la créativité du législateur. Au final on aboutit à un modèle normalisé (SGBDR oblige et quoi qu'en dise ses détracteurs MySQL est un vrai SGBDR...) qui ne doit pas faire peur à des développeurs parce qu'il ne contient aucune colonne 'DEFAULT NULL' et qu'il nécessitera moult jointures...

    J'en viens donc à la spécialisation concernant le relationnel : la maîtrise d'un modèle passe par cette spécialisation et malheureusement, je dois constater que les développeurs qu'ils soient JAVA ou PHP sont plus spécialisés sur des frameworks que sur les bases relationnelles (pratiquer SQL ne fait pas de vous un spécialiste du relationnel !). Utiliser ces fonctionnalités de MySQL (ou autres...) est pour moi un parti pris visant à une meilleure utilisation du moteur relationnel embarqué dans la base de données.

    Terminons par les performances, puisque cela préoccupe. Cette solution a remporté très largement un bench contre un logiciel de paye du marché qui a pignon sur rue (et qui ne s'adresse pas qu'à la TPE !) sur des imports en masse de salaires ( 9 mois de salaires pour une société de portage salarial dont le métier est justement de produire en masse des bulletins de salaires).

    En conclusion, écrire qu'il est déconseillé d'utiliser les procédures stockées et que "MySql n'est pas bon pour ce genre de chose" me semble une affirmation sans fondement.

    Bien cordialement.

  15. #15
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    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 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Tout a fait d'accord avec vous et j'ai écrit depuis longtemps sur ce point, notamment dans cet article publié il y a longtemps :
    http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

    Citation Envoyé par isabelle.letrong Voir le message
    ...quoi qu'en dise ses détracteurs MySQL est un vrai SGBDR...
    En revanche sur cette affirmation. Non !
    Il échoue à au moins 4 des 12 règles de Codd en plus d'être farci de bugs... :
    http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

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

Discussions similaires

  1. Performance de des procédures stockée SQL Serveur
    Par tawrirte dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 30/10/2011, 07h46
  2. Réponses: 11
    Dernier message: 15/02/2011, 01h10
  3. [CR][VB6] Utilisation des procédures stockées
    Par couledoux dans le forum SDK
    Réponses: 3
    Dernier message: 10/03/2005, 15h29
  4. Réponses: 5
    Dernier message: 04/10/2004, 19h20
  5. importer des procédures stockées
    Par mohamed dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 10/09/2004, 17h30

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