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 est heureusement capable d'utiliser du 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é, c'était SQL
beaucoup plus rapide que d'utiliser un ORM. Mais parle-t-il en faveur des procédures stockées ou seulement contre l'utilisation de l' 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 UPDATE et votre problème est terminé. Ce problème pourrait être résolu même avec un ORM : il
suffit d' utiliser un webservice en face de l'autre DB et la même segmentation / isolation est obtenue.
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 lorsque cela est approprié.
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 d' 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 pars avec un peut - être .
Jusqu'à présent, seulement un demi- point a été fait 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 présente l'avantage d'un simple appel à 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, 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é plaidé pour le stockage de 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 pour ni contre les procédures stockées, mais contre les 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 approprié qui parle sans équivoque pro.
Quand dois-je utiliser des procédures stockées?
La bonne réponse est: quand vous le souhaitez . Mais il existe d'autres options.