Quand dois-je utiliser des procédures stockées?
Si j'ai toute ma logique métier dans le code et que j'utilise Entity Framework, dans quelles situations (le cas échéant) serais-je mieux de déplacer une logique métier vers une procédure stockée, au lieu de tout garder dans le code?
Pour être clair, je veux dire en conjonction avec la configuration actuelle (logique métier dans le code), pas à la place de. J'ai vu un certain nombre de questions similaires qui demandent les avantages et les inconvénients d'avoir toute la logique métier dans les procédures stockées, mais je n'ai pas trouvé grand-chose concernant l'utilisation modérée des procédures stockées pour la logique de cas Edge, tout en conservant le reste de la logique métier dans du code.
Si cela fait une différence, j'utilise MSSQL et Entity Framework.
Ce sont les situations où j'ai déjà utilisé des procédures stockées:
- Un rapport compliqué qui prenait des minutes à exécuter (c'était une page dans une application web). J'ai trouvé que je pouvais écrire du SQL beaucoup plus efficace (ne prenant que quelques secondes à exécuter) que ce que LINQ fournissait.
- Une application Web devait lire et écrire dans quelques tables d'une base de données distincte qui contenait beaucoup d'autres informations sensibles qui n'étaient pas pertinentes pour l'application. Plutôt que de lui donner accès à tout, j'ai utilisé une procédure stockée qui ne fait que ce qui est nécessaire et ne renvoie que des informations limitées. L'application Web pourrait alors avoir accès uniquement à cette procédure stockée, sans accès à des tables, etc.
Autres articles que j'ai consultés avant de poser cette question:
- Les procédures stockées sont une mauvaise pratique dans l'une des plus grandes sociétés de conseil en logiciels informatiques au monde?
- Avantages et inconvénients de conserver toute la logique métier dans les procédures stockées dans l'application Web
- https://stackoverflow.com/questions/15142/what-are-the-pros-and-cons-to-keeping-sql-in-stored-procs-versus-code
- https://dba.stackexchange.com/questions/2450/what-are-the-arguments-against-or-for-putting-application-logic-in-the-database/2452#2452
- Quand ne pas utiliser ORM et préférer les procédures stockées?
Vous avez déjà quelques scénarios parfaitement bons.
Il y a aussi beaucoup d'autres raisons. EF est vraiment bon au CRUD et au reporting assez simple. Parfois, cependant, EF n'est pas l'outil parfait. Voici d'autres raisons (scénarios) d'envisager l'utilisation de procédures stockées en combinaison avec Entity Framework:
- Vous avez des unités de travail complexes, impliquant peut-être de nombreuses tables, qui ne peuvent pas être encapsulées facilement dans une transaction à l'aide des fonctionnalités d'EF.
- Votre base de données ne fonctionne pas bien avec EF car elle ne tire pas parti de l'intégrité référentielle déclarative (contraintes de clé étrangère). Il s'agit généralement d'un mauvais scénario dans lequel vous vous trouvez, mais il existe parfois des scénarios appropriés, tels que des bases de données utilisées pour les processus ETL.
- Vous devez travailler avec des données qui traversent les frontières du serveur avec des serveurs liés.
- Vous disposez de scénarios de récupération de données très complexes où un SQL "nu" est nécessaire pour garantir des performances adéquates. Par exemple, vous avez des jointures complexes qui nécessitent des conseils de requête pour bien fonctionner dans votre situation spécifique.
- Votre application ne dispose pas des autorisations CRUD complètes sur une table, mais votre application peut être autorisée à s'exécuter dans un contexte de sécurité auquel votre serveur fait confiance (identité de l'application, plutôt que l'identité de l'utilisateur, par exemple). Cela peut se produire dans des situations où les administrateurs de base de données limitent l'accès aux tables aux proc stockés uniquement parce que cela leur donne un contrôle plus granulaire sur qui peut faire quoi.
Je suis sûr qu'il y en a beaucoup plus en plus. La façon de déterminer la meilleure voie à suivre dans toute circonstance particulière est d'utiliser un certain bon sens et de se concentrer sur l'objectif principal, qui devrait être d'écrire du code de haute qualité et facilement maintenable. Choisissez le ou les outils qui vous donnent ce résultat dans chaque cas.
Peut-être que cela a du sens, de tourner la question et de trouver des cas où seules les procédures stockées pourraient faire, ce que vous voulez réaliser. Il existe peut-être vraiment des cas d'utilisation, où les procédures stockées se démarquent.
Si cela fait une différence, j'utilise MSSQL et Entity Framework.
Mes connaissances sur EF sont limitées, mais pour autant que je puisse voir, EF est ( juste ) un ORM comme les autres; et heureusement est capable d'utiliser SQL brut .
Si je prends vos deux points principaux:
Un rapport compliqué qui prenait des minutes à exécuter (c'était une page dans une application web). J'ai trouvé que je pouvais écrire du SQL beaucoup plus efficace (ne prenant que quelques secondes à exécuter) que ce que LINQ fournissait.
[~ # ~] linq [~ # ~] / [~ # ~] ef [~ # ~] n'était pas à la hauteur lors de la rédaction d'un rapport. Et comme vous l'avez remarqué, était SQL beaucoup plus rapide que d'utiliser un ORM. Mais parle ceci en faveur des procédures stockées ou seulement contre l'utilisation de [~ # ~] orm [~ # ~ ] pour tout?
Votre problème pourrait évidemment être résolu avec [~ # ~] sql [~ # ~] . Si cette requête a été stockée et la version contrôlée dans votre base de code ne fait - selon votre exemple - au moins aucune différence .
Une application Web devait lire et écrire dans quelques tables d'une base de données distincte qui contenait beaucoup d'autres informations sensibles qui n'étaient pas pertinentes pour l'application. Plutôt que de lui donner accès à tout, j'ai utilisé une procédure stockée qui ne fait que ce qui est nécessaire et ne renvoie que des informations limitées. L'application Web pourrait alors avoir accès uniquement à cette procédure stockée, sans accès à des tables, etc.
Même chose ici: une simple chaîne de connexion et et [~ # ~] met à jour [~ # ~] et votre problème est terminé. Ce problème pourrait être résolu même avec un [~ # ~] orm [~ # ~] : simplement utiliser un webservice devant l'autre DB et la même compartimentationalisation / l'isolement est atteint.
Donc rien à voir ici.
En examinant certains points que d'autres ont soulevés:
Vous avez des unités de travail complexes, impliquant peut-être de nombreuses tables, qui ne peuvent pas être encapsulées facilement dans une transaction à l'aide des fonctionnalités d'EF.
Mais SQL peut le faire. Pas de magie impliquée ici.
Votre base de données ne fonctionne pas bien avec EF
Encore une fois: utilisez [~ # ~] ef [~ # ~] le cas échéant.
Vous devez travailler avec des données qui traversent les frontières du serveur avec des serveurs liés
Je ne vois pas comment les procédures stockées aident. Je ne peux donc pas voir un avantage des procédures stockées; mais peut-être que quelqu'un fait la lumière là-dessus.
Vous avez des scénarios de récupération de données très complexes où un SQL "nu" est nécessaire afin d'assurer des performances adéquates
Encore une fois: "Limites de [~ # ~] ef [~ # ~] ".
Votre application ne dispose pas des autorisations CRUD complètes sur une table, mais votre application peut être autorisée à s'exécuter dans un contexte de sécurité auquel votre serveur fait confiance
D'accord. Je vais avec un peut-être .
Jusqu'à présent, seul un demi-point a été avancé en faveur des procédures stockées.
Il existe peut-être des considérations de performances, qui parlent en faveur des procédures stockées.
1) Le stockage des requêtes a l'avantage d'un appel simple à la procédure stockée qui résume la complexité. Étant donné que le planificateur de requêtes connaît la requête, son optimisation est "plus facile". Mais les sauvegardes se font avec le planificateur de requêtes sophistiqué actuel _minimal.
En plus de cela, même s'il y a un léger coût en utilisant des requêtes ad hoc , si vos données sont bien structurées et soigneusement indexées, le la base de données n'est que le goulot d'étranglement de votre application. Donc, même s'il y a un petit delta, il est négligeable compte tenu d'autres facteurs.
2) Néanmoins, il a été suggéré de stocker des requêtes complexes dans une base de données. Il y a deux choses à considérer:
a) les requêtes complexes utilisent massivement l'infrastructure DB, ce qui augmente les temps de réponse pour toutes les autres requêtes. Vous ne pouvez pas exécuter de nombreuses requêtes coûteuses en parallèle . Cela ne parle ni pro ni contra les procédures stockées, mais contre requêtes complexes .
b) Si la requête prend de toute façon du temps, pourquoi s'embêter avec de petites victoires de vitesse d'une procédure stockée.
tl; dr
Rien ne parle directement contre les procédures stockées. Il est donc acceptable d'utiliser des procédures stockées - si cela vous rend heureux.
Mais d'un autre côté: je ne pouvais pas imaginer un cas d'utilisation correct qui parle sans équivoque pro.
Quand dois-je utiliser des procédures stockées?
La bonne réponse est: chaque fois que vous le souhaitez . Mais il existe d'autres options.
Je déconseille fortement de placer toute logique entreprise dans une procédure stockée. Cependant, il peut y avoir un cas (vous avez énuméré deux beaux exemples) où il est préférable de placer la logique accès aux données là-bas.
De manière générale, si vous êtes tenté d'utiliser des SP, c'est un signe (une odeur de code) laissant entendre que votre modèle de données n'est pas bien adapté à ses besoins.
Edit: lorsque les développeurs me posent des questions sur la logique d'accès aux données/aux entreprises, je dis que la logique métier concerne la façon dont les données se comportent et interagissent, tandis que la logique d'accès aux données concerne la façon dont les données sont stockées et récupérées.
Par exemple: Dans votre modèle de domaine, vous pourriez avoir les entités "Student" et "Teacher", toutes deux dérivées de "Person". (Ne pas dire que c'est préférable, juste un exemple). Cela peut être stocké dans une base de données relationnelle sous la forme d'une, deux ou trois tables. Le choix dépend du nombre de propriétés qu'ils partagent et des exigences de performances en lecture/écriture.
Dans la logique métier, la façon dont ces entités sont stockées n'a pas d'importance. (ou s'ils résident dans un RDB). La logique d'accès aux données concerne leur stockage physique.
Donc, en ce qui concerne la question d'origine: si une procédure stockée rend le stockage et la récupération de données plus efficaces (ou plus robustes), vous avez un cas. Si la procédure stockée vise simplement à imposer une règle que je valide quelle que soit la façon dont les données sont stockées, évitez-la. Cela rend votre code plus étroitement couplé à la base de données.
Pour votre cas spécifique, étant donné que vous utilisez l'infrastructure d'entité, il convient d'envisager d'utiliser des procédures stockées lorsque l'infrastructure d'entité ne répond pas à une exigence ou à une préoccupation.
Le cadre d'entité fait un travail décent et les performances seront proches ou égales à l'utilisation de procédures stockées. Vous avez choisi le framework d'entité parce que vous ne vouliez pas vous préoccuper de SQL et laissez le framework générer le SQL pour vous.
Mais il peut y avoir un cas Edge où le cadre d'entité est défaillant et ne peut pas répondre à vos besoins. Dans ce cas, on doit écrire le SQL à la main à l'aide d'une procédure stockée ou d'une requête paramétrée, puis utiliser le framework d'entité pour appeler directement cette procédure stockée/instruction SQL.
Donc, je ne déplacerais rien vers une procédure stockée à moins que le cadre utilisé ne puisse pas répondre à l'exigence.
Je pense que la pire chose qui puisse arriver est que l'on choisisse d'utiliser le framework d'entité et ensuite d'écrire toutes les procédures stockées. Maintenant, on a une couche supplémentaire qui n'ajoute aucune valeur.
Avoir un besoin technique n'est pas le choix le plus probable. Les programmeurs préfèrent leurs outils et sont généralement plus à même de résoudre leurs problèmes avec eux. Mettre la logique dans un sproc sera l'exception. La dette technique et les futurs développeurs devant prendre du temps pour travailler avec une exception doivent être pris en considération. Il peut y avoir une amélioration des performances dans votre SGBDR particulier qui est simplement plus facile à implémenter dans un sproc ou peut-être même un autre objet db comme une vue indexée.
Il y aura des moments où vous aurez besoin de données d'une base de données et que vous ne pourrez tout simplement pas les obtenir à partir de votre code d'application. Dans de nombreuses situations de grande entreprise/entreprise, les besoins de l'entreprise peuvent dépasser la portée du service informatique. Les entreprises sont achetées et vendues et leurs applications vont et viennent avec elles. Les agences de régulation et les banques ne se soucient pas si vous ne pouvez pas créer votre application hautement évolutive et magnifiquement codée. Ils peuvent rendre la vie difficile à l'entreprise, vous devez donc le faire.
J'ai rencontré des situations où des applications tierces ou des outils d'écriture de rapports ne vous permettent pas d'accéder à votre code. Pas de code open source, pas d'API, pas d'interface web et pas de services. La seule chose qu'ils ont est leur propre outil spécial d'écriture de rapport qui ne fonctionne qu'avec des objets de base de données: tables, vues, sprocs, fonctions définies par l'utilisateur, etc. Vous mettez la logique partout où vous pouvez y accéder.
Si vous avez un DBA qui est très bon pour écrire des procédures stockées, vous pouvez tirer parti de ce talent dans certaines situations. Vous souhaiterez peut-être déclencher une sauvegarde à partir de votre application, car vous allez apporter une modification majeure aux données, alors pourquoi ne pas utiliser ce que votre dba utilise?
Certaines demandes ad hoc sont simplement plus faciles à écrire un proc jusqu'à ce que vous puissiez obtenir toutes les fonctionnalités de votre application. Nous détestons ça. Nous repoussons, mais le spectacle doit continuer.