Les procédures stockées MySQL les utilisent ou ne pas les utiliser
Nous sommes au début d'un nouveau projet et nous nous demandons vraiment si nous devrions utiliser des procédures stockées dans MySQL ou non.
Nous utiliserions les procédures stockées uniquement pour insérer et mettre à jour des entités de modèle métier. Il y a plusieurs tables qui représentent une entité modèle et nous l'abstruirions dans les procédures stockées insérées/mises à jour.
D'autre part, nous pouvons appeler insert et update à partir de la couche Model mais pas dans MySQL mais en PHP.
D'après votre expérience, Quelle est la meilleure option? avantages et inconvénients des deux approches. Quel est le plus rapide en termes de haute performance?
PS: C’est un projet Web avec une majorité de lecture et une performance élevée est la condition la plus importante.
Contrairement au code de langage de programmation actuel, ils:
- non portable (chaque base de données a sa propre version de PL/SQL. Des versions différentes de la base de données same sont parfois incompatibles - je l'ai déjà vue!)
- pas facilement testable - vous avez besoin d'une instance de base de données real (dev) pour les tester; ainsi, il est pratiquement impossible de tester leur code dans le cadre d'une construction
- difficile à mettre à jour/libérer - vous devez les supprimer/créer, c.-à-d. modify la base de production pour les libérer
- ne pas avoir de support de bibliothèque (pourquoi écrire du code quand quelqu'un d'autre en a)
- ne sont pas faciles à intégrer à d'autres technologies (essayez d'appeler un service Web à partir d'eux)
- ils utilisent un langage aussi primitif que Fortran et sont donc inélégants et laborieux pour coder utilement. Il est donc difficile d'exprimer une logique métier, même si c'est en général leur objectif premier.
- n'offrent pas de débogage/traçage/enregistrement de messages, etc. (certaines dbs peuvent le supporter - je ne l'ai pas encore vu)
- manque un IDE décent pour aider avec la syntaxe et la liaison avec d'autres procédures existantes (par exemple, comme Eclipse le fait pour Java)
- les personnes qualifiées pour les coder sont plus rares et plus chères que les codeurs d'applications
- leur "haute performance" est un mythe, car ils exécutent généralement sur le serveur de base de données augmentent la charge du serveur de base de données; leur utilisation permettra donc de réduire votre débit de transaction maximal
- incapacité à partager efficacement les constantes (généralement résolu en créant une table et en la cherchant depuis votre procédure - très inefficace)
- etc.
Si vous avez une action très spécifique à la base de données (par exemple, une action en transaction pour maintenir l'intégrité de la base de données), ou maintenez vos procédures très simples et atomiques, vous pourriez peut-être les envisager.
La prudence est recommandée lors de la spécification "haute performance" à l’avance. Cela conduit souvent à de mauvais choix au détriment d'un bon design et cela vous piquera beaucoup plus tôt que vous ne le pensez.
Utilisez des procédures stockées à vos risques et périls (de la part de quelqu'un qui y est allé et qui ne veut jamais revenir en arrière). Ma recommandation est de les éviter comme la peste.
Contrairement au code de programmation, ils:
- rendre les attaques par injection SQL presque impossibles (sauf si vous êtes
construction et exécution dynamique
SQL depuis vos procédures) - nécessite beaucoup moins de données à envoyer sur le IPC dans le cadre de la légende
- activer la base de données pour améliorer beaucoup mieux les plans de cache et les ensembles de résultats.
- sont facilement testables en isolation (c’est-à-dire pas dans le cadre des tests JUnit)
- sont portables dans le sens où ils vous permettent d'utiliser des fonctionnalités spécifiques à la base de données, abstraites derrière un nom de procédure
- ne sont presque jamais plus lents que SQL appelé depuis le code
mais, comme le dit Bohemian, il y a aussi beaucoup d'inconvénients (c'est simplement pour offrir une autre perspective). Vous devrez peut-être comparer vos performances avant de décider ce qui vous convient le mieux.
Quant aux performances, elles ont le potentiel d'être vraiment performant dans une future version de MySQL (sous SQL Server ou Oracle, c'est un vrai régal!). Pourtant, pour tout le reste ... Ils font totalement exploser la concurrence. Je vais résumer:
Sécurité: vous pouvez donner à votre application le droit EXECUTE uniquement, tout va bien. Votre SP insérera la mise à jour, sélectionnez ..., sans fuite possible. Cela signifie un contrôle global sur votre modèle et une sécurité des données renforcée.
Sécurité 2: Je sais que c'est rare, mais parfois le code php s'échappe du serveur (devient visible pour le public). Si cela inclut vos requêtes, les attaquants éventuels connaissent votre modèle. C'est assez étrange mais je voulais quand même le signaler
Task force: oui, la création de SP SQL efficaces nécessite des ressources spécifiques, parfois plus coûteuses. Mais si vous pensez que vous n’avez pas besoin de ces ressources simplement parce que vous intégrez vos requêtes à votre client, vous allez avoir de graves problèmes. Je voudrais mentionner l'analogie du développement Web: il est bon de séparer la vue des autres car votre concepteur peut travailler sur sa propre technologie tandis que les programmeurs peuvent se concentrer sur la programmation de la couche de gestion.
Couche métier encapsulante: l'utilisation de procédures stockées isole totalement l'entreprise à laquelle elle appartient: la base de données.
Rapidement testable: une ligne de commande sous votre shell et votre code est testé.
Indépendance par rapport à la technologie client: si demain vous souhaitez passer de php à autre chose, pas de problème. Ok, le simple fait de stocker ces SQL dans un fichier séparé ferait l'affaire aussi, c'est vrai. Aussi, bon point dans les commentaires sur si vous décidez de changer de moteur SQL, vous aurez beaucoup de travail à faire. De toute façon, il faut avoir une bonne raison de le faire, car cela arrive rarement pour les grands projets et les grandes entreprises (principalement en raison des coûts et de la gestion des ressources humaines).
Application de développements agiles de niveau 3 +: si votre base de données ne se trouve pas sur le même serveur que votre code client, vous pouvez avoir plusieurs serveurs mais un seul pour la base de données. Dans ce cas, vous ne devez mettre à jour aucun de vos serveurs php lorsque vous devez modifier le code associé à SQL.
Ok, je pense que c'est la chose la plus importante que j'ai à dire sur le sujet. J'ai développé dans les deux spiritueux (SP vs client) et j'adore vraiment le style SP. Je voulais juste que Mysql ait un vrai IDE pour eux parce que maintenant c'est un peu une douleur dans le cul limité.
Les procédures stockées sont bonnes à utiliser car elles gardent vos requêtes organisées et vous permettent d'effectuer un lot à la fois. Les procédures stockées s'exécutent généralement rapidement, car elles sont précompilées, contrairement aux requêtes compilées à chaque exécution. Cela a un impact significatif dans les situations où la base de données est sur un serveur distant; si les requêtes sont dans un script PHP, il existe plusieurs communications entre l'application et le serveur de base de données - la requête est envoyée, exécutée et le résultat renvoyé. Toutefois, si vous utilisez des procédures stockées, il vous suffit d'envoyer une petite instruction CALL au lieu de grandes requêtes compliquées.
L'adaptation à la programmation d'une procédure stockée peut prendre un certain temps, car elle possède son propre langage et sa propre syntaxe. Mais une fois que vous êtes habitué, vous verrez que votre code est vraiment propre.
En termes de performances, il peut ne pas y avoir de gain significatif si vous utilisez des procédures stockées ou non.
Je ferai connaître mon opinion, même si mes opinions ne sont peut-être pas directement liées à la question.
Comme dans de nombreux cas, les réponses sur l'utilisation de procédures stockées ou d'une solution pilotée par la couche d'application reposent sur des questions qui conduiront à l'effort global:
- Ce que vous voulez obtenir.
Essayez-vous d'effectuer des opérations par lots ou des opérations en ligne? Sont-ils complètement transactionnels? à quel point ces opérations sont-elles récurrentes? Quelle est la charge de travail attendue pour la base de données?
- Qu'est-ce que vous avez pour l'obtenir.
Quel type de technologie de base de données avez-vous? Quel type d'infrastructure? Votre équipe est-elle entièrement formée à la technologie de base de données? Votre équipe est-elle mieux à même de construire une solution basée sur une base de données?
- Temps pour l'obtenir.
Aucun secret à ce sujet.
- Architecture.
Votre solution doit-elle être distribuée sur plusieurs sites? Votre solution est-elle nécessaire pour utiliser les communications à distance? votre solution fonctionne-t-elle sur plusieurs serveurs de base de données ou utilise-t-elle éventuellement une architecture en cluster?
- Mainteinance.
Combien demande l'application pour changer? Avez-vous un personnel spécialement formé pour maintenir la solution?
- Gestion du changement.
Voyez-vous votre technologie de base de données changera à court, moyen, long terme? voyez-vous qu'il sera nécessaire de migrer la solution fréquemment?
- Coût
Combien coûtera la mise en œuvre de cette solution en utilisant l’une ou l’autre des stratégies?
L'ensemble de ces points conduira la réponse. Vous devez donc vous préoccuper de chacun de ces points lorsque vous prenez la décision d'utiliser ou non une stratégie. Il existe des cas où l'utilisation de procédures stockées est préférable aux requêtes gérées au niveau de la couche application, et dans d'autres cas, il est préférable de mener des requêtes et d'utiliser une solution basée sur la couche application.
L'utilisation de procédures stockées a tendance à être plus appropriée lorsque:
- Votre technologie de base de données n'est pas fournie pour changer à court terme.
- Votre technologie de base de données peut gérer des opérations parallélisées, des partitions de table ou toute autre stratégie permettant de diviser la charge de travail en plusieurs processeurs, mémoire et ressources (clustering, grille).
- Votre technologie de base de données est entièrement intégrée au langage de définition de procédure stockée, ce qui signifie que la prise en charge se trouve dans le moteur de base de données.
- Vous avez une équipe de développement qui n'a pas peur d'utiliser un langage procédural (langage de 3ème génération) pour obtenir un résultat.
- Les opérations que vous souhaitez réaliser sont intégrées ou prises en charge dans la base de données (exportation vers des données XML, gestion de l'intégrité et de la cohérence des données de manière appropriée avec des déclencheurs, des opérations planifiées, etc.).
- La portabilité n'est pas un problème important et vous ne modifiez pas rapidement la technologie dans votre organisation, même si cela n'est pas souhaitable. En règle générale, la portabilité est perçue comme une étape importante par les développeurs orientés applications et couches. De mon point de vue, la portabilité ne pose pas de problème lorsque votre application n'est pas obligée d'être déployée sur plusieurs plates-formes, moins lorsqu'il n'y a aucune raison de changer de technologie ou que l'effort de migration de toutes les données organisationnelles est supérieur à celui requis. l'avantage de faire un changement. Ce que vous pouvez gagner en utilisant une approche basée sur la couche d'application (portabilité), vous pouvez perdre en performances et en valeur obtenues à partir de votre base de données (Pourquoi dépenser des milliers de dollars pour obtenir une Ferrari ne conduisant pas à plus de 60 milles/h ?).
- La performance est un problème. Premièrement: dans plusieurs cas, vous pouvez obtenir de meilleurs résultats en utilisant un seul appel de procédure stockée que plusieurs demandes de données provenant d'une autre application. De plus, certaines caractéristiques que vous devez exécuter peuvent être intégrées à votre base de données et son utilisation moins coûteuse en termes de charge de travail. Lorsque vous utilisez une solution pilotée par la couche application, vous devez prendre en compte le coût associé aux connexions à la base de données, aux appels à la base de données, au trafic réseau, au wrapping des données (en utilisant Java ou .NET, il existe un coût implicite lorsque l’utilisation d’appels JDBC/ADO.NET car vous devez encapsuler vos données dans des objets qui représentent les données de la base de données, de sorte que l’instanciation a un coût associé en termes de traitement, de mémoire et de réseau lorsque les données proviennent de l’extérieur).
L'utilisation de solutions basées sur la couche application a tendance à être plus appropriée lorsque:
- La transférabilité est un problème important.
- L'application sera déployée sur plusieurs emplacements avec un ou plusieurs référentiels de base de données.
- Votre application utilisera des règles lourdes orientées métier, qui doivent être indépendantes de la technologie de base de données sous-jacente.
- Vous envisagez de changer de fournisseur de technologie en fonction des tendances du marché et du budget.
- Votre base de données n'est pas complètement intégrée à la langue de la procédure stockée qui appelle la base de données.
- Les capacités de votre base de données sont limitées et vos exigences vont au-delà de ce que vous pouvez réaliser avec votre technologie de base de données.Votre application peut supporter la pénalité inhérente aux appels externes, est davantage transactionnelle avec des règles spécifiques à l'entreprise et doit résumer le modèle de base de données sur un modèle commercial pour les utilisateurs.
- La parallélisation des opérations de base de données n'a pas d'importance, de plus, votre base de données ne dispose pas de capacités de parallélisation.
- Vous avez une équipe de développement qui n'est pas bien formée à la technologie de base de données et qui est plus productive en utilisant une technologie basée sur les applications.
- J'espère que cela pourra aider quiconque se demandant ce qu'il vaut mieux utiliser.
Hope this may help to anyone asking himself/herself what is better to use.
Je vous recommande de ne pas utiliser de procédures stockées:
- Leur langage dans MySQL est très nul
- Il n'y a aucun moyen d'envoyer des tableaux, des listes ou d'autres types de structure de données dans une procédure stockée
- Une procédure stockée ne peut jamais changer d'interface; MySQL n'autorise ni paramètres nommés, ni paramètres optionnels
- Cela rend le déploiement de nouvelles versions de votre application plus compliqué - supposons que vous ayez 10 serveurs d'applications et 2 bases de données, que mettez-vous à jour en premier?
- Vos développeurs ont tous besoin d'apprendre et de comprendre le langage de procédure stockée - ce qui est très merdique (comme je l'ai déjà mentionné)
Au lieu de cela, je recommande de créer une couche/bibliothèque et de mettre toutes vos requêtes là
Vous pouvez
- Mettez à jour cette bibliothèque et envoyez-la sur vos serveurs d'applications avec votre application.
- Faire passer des types de données riches, tels que des tableaux, des structures, etc.
- Tester cette bibliothèque à la place des procédures stockées.
Sur la performance:
- L'utilisation de procédures stockées réduira les performances de vos développeurs d'applications, ce qui est votre principale préoccupation.
- Il est extrêmement difficile d'identifier les problèmes de performances au sein d'une procédure stockée complexe (cela est beaucoup plus simple pour les requêtes simples).
- Vous pouvez soumettre un lot de requêtes en un seul bloc sur le réseau (si l'indicateur CLIENT_MULTI_STATEMENTS est activé), ce qui signifie que vous n'obtenez plus de temps d'attente sans procédures stockées.
- Le code côté application est généralement meilleur que le code côté base de données
Si votre base de données est complexe et qu'il ne s'agit pas d'un type de forum avec réponses, le véritable entreposage SP en bénéficiera certainement. Vous pouvez y inclure toute votre logique métier et aucun développeur ne s'en soucie, ils appellent simplement votre SP. Je ne me suis pas amusé à joindre 15 tables, et vous ne pouvez pas l'expliquer à un nouveau développeur.
Les développeurs n'ont pas non plus accès à une base de données, super! Laissez cela aux concepteurs et aux responsables de la base de données. Si vous décidez également que la structure de la table va être modifiée, vous pouvez le masquer derrière votre interface. n-Tier, tu te souviens ??
Les hautes performances et les bases de données relationnelles ne vont pas de pair. Même avec MySQL InnoDB, le logiciel doit être jeté par la fenêtre. Si vous avez besoin de performances avec une application Web, vous avez besoin d'un cache, d'un memcache ou autres.
dans votre cas, parce que vous avez parlé de "Web", je n'utiliserais pas de procédures stockées. Si c'était un entrepôt de données, je le prendrais certainement en compte (nous utilisons des SP pour notre entrepôt).
Astuce: Depuis que vous avez mentionné Web-project, avez-vous déjà pensé à une solution de ce type? En outre, vous avez besoin d'une base de données rapide, pourquoi ne pas utiliser PostgreSQL? (essayant de défendre ici ...)
J'avais l'habitude d'utiliser MySql et ma compréhension de SQL était au mieux médiocre, j'ai passé assez de temps à utiliser SQL Server, j'ai une séparation claire entre une couche de données et une couche d'application, je recherche actuellement un serveur avec 0,5 téraoctets.
Je me suis parfois senti frustré de ne pas utiliser un ORM car le développement est très rapide avec les procédures stockées, il est beaucoup plus lent. Je pense qu'une grande partie de notre travail aurait pu être accélérée en utilisant un ORM.
Lorsque votre application atteindra une masse critique, les performances de l'ORM en souffriront. Une procédure stockée bien écrite vous donnera les résultats plus rapidement.
À titre d’exemple, je collecte 10 types de données différents dans une application, puis les convertis au format XML, que je traite dans la procédure stockée. J’ai un appel à la base de données au lieu de 10.
SQL est vraiment bon pour gérer des ensembles de données, ce qui me rend frustré quand je vois quelqu'un récupérer des données de SQL dans une forme brute et utiliser le code d'application pour parcourir les résultats et les mettre en forme et les regrouper; c'est vraiment une mauvaise pratique .
Mon conseil est d’apprendre et de comprendre suffisamment SQL et vos applications en bénéficieront vraiment.
Beaucoup d'informations ici pour confondre les gens, le développement de logiciels est une évolution. Ce que nous avons fait il y a 20 ans n'est pas la meilleure pratique pour le moment. De retour dans la journée avec un serveur client classique, vous ne rêvez que de SP.
Ce sont des chevaux pour les cours, si vous êtes une grande organisation, vous utiliserez plusieurs niveaux, et probablement des SP, mais vous vous en soucierez peu car une équipe dédiée les triera.
Au contraire, c’est là que je me trouve à essayer de créer rapidement une solution d’application Web, qui précise les besoins de l’entreprise, c’était très rapide de laisser le développeur (distant pour moi) détruire les pages et les requêtes SQL et définir le DB structure.
Cependant, la complexité augmente et sans un moyen simple de fournir des API, je souhaite utiliser des SP pour contenir la logique métier. Je pense que cela fonctionne bien et que je le contrôle, car je peux construire une logique et fournir un ensemble de résultats simple à mon développeur offshore pour créer un front-end.
Si mon logiciel rencontre un succès phénoménal, il faudra séparer davantage les problèmes et mettre en œuvre différentes applications, mais pour le moment, les SP sont parfaits.
Vous devez connaître tous les outils disponibles et les assortir est sage de commencer. Sauf si vous construisez un système d'entreprise pour commencer, il est préférable de procéder rapidement et simplement.
Je vous recommande de rester à l'écart des procédures stockées spécifiques à la DB.
J'ai traversé de nombreux projets où ils souhaitent soudainement changer de plate-forme de base de données et où le code à l'intérieur d'un SP n'est généralement pas très portable = travail supplémentaire et erreurs possibles.
Le développement de procédures stockées nécessite également que le développeur ait directement accès au moteur SQL, une connexion normale pouvant être modifiée par n'importe qui dans le projet disposant uniquement d'un accès au code.
Concernant votre idée de modèle/couche/niveau: oui, tenez-vous-en à cela.
- Couche Affaires (BL) des appels de sites Web
- BL appelle couche de données (DL)
- DL appelle quel que soit le stockage (SQL, XML, Webservice, Sockets, Textfiles, etc.)
De cette façon, vous pouvez maintenir le niveau logique entre les niveaux. SI et UNIQUEMENT SI les appels DL semblent être très lents, vous pouvez commencer à bricoler avec les procédures stockées, mais en conservant le code d'origine sans SP, quelque part, si vous devez soudainement transférer la base de données sur une toute nouvelle plateforme. . Avec tous les services d'hébergement en nuage sur le marché, vous ne savez jamais quelle sera la prochaine plateforme de base de données ...
Je surveille de près Amazon AWS pour la même raison.
Je pense qu'il y a beaucoup de fausses informations sur les requêtes stockées dans les bases de données.
Je recommanderais d'utiliser les procédures stockées MySQL si vous effectuez de nombreuses requêtes statiques pour la manipulation de données. Surtout si vous déplacez des objets d’une table à l’autre (c’est-à-dire que vous passez d’une table en direct à une table historique pour une raison quelconque). Il y a bien sûr des inconvénients, car vous devez tenir un journal séparé de leurs modifications (vous pouvez théoriquement créer un tableau contenant uniquement les modifications apportées aux procédures stockées mises à jour par l'administrateur de la base de données). Si de nombreuses applications s'interfacent avec la base de données, en particulier si vous avez un programme de bureau écrit en C # et un programme Web en PHP, il serait peut-être plus avantageux de stocker certaines de vos procédures dans la base de données car elles sont indépendantes de la plate-forme.
Ce site Web contient des informations intéressantes qui pourraient vous être utiles.
https://www.sitepoint.com/stored-procedures-mysql-php/
Comme toujours, créez d'abord un bac à sable et testez-le.