Procédures stockées et ORM
Quel est le but des procédures stockées par rapport à l'utilisation d'un ORM (nHibernate, EF, etc.) pour gérer certaines opérations CRUD? Pour appeler la procédure stockée, nous ne faisons que passer quelques paramètres et avec un ORM nous envoyons toute la requête SQL, mais est-ce juste une question de performance et de sécurité ou y a-t-il plus d'avantages?
Je demande cela parce que je n'ai jamais utilisé de procédures stockées (j'écris juste toutes les instructions SQL avec un ORM et les exécute), et un client m'a dit que j'aurais pour travailler avec des procédures stockées dans mon prochain projet, j'essaie de savoir quand les utiliser.
5 réponses
Les procédures stockées sont souvent écrites dans un dialecte de SQL (T-SQL pour SQL Server, PL-SQL Oracle, etc.). C'est parce qu'ils ajoutent des fonctionnalités supplémentaires à SQL pour le rendre plus puissant. D'autre part, vous avez un ORM, disons NH qui génère SQL.
Les instructions SQL générées par L'ORM n'ont pas la même vitesse ou la même puissance d'écriture des procédures stockées T-SQL. Voici où le dilemme entre: ai-je besoin d'une application super rapide liée à un fournisseur de base de données SQL, difficile à maintenir ou Ai-je besoin d'être flexible car j'ai besoin de cibler plusieurs bases de données et je préfère réduire le temps de développement en écrivant des requêtes HQL que des requêtes SQL?
Les procédures stockées sont plus rapides que les instructions SQL car elles sont pré-compilées dans le moteur de base de données, avec des plans d'exécution mis en cache. Vous ne pouvez pas le faire en NH, mais vous avez d'autres alternatives, comme l'utilisation du niveau de Cache 1 ou 2.
Aussi, essayez de faire des opérations en vrac avec NH. Les procédures stockées fonctionnent très bien dans ces cas. Vous avez besoin de considérez que SP parle à la base de données à un niveau plus profond.
Le choix n'est peut-être pas si évident car tout dépend du scénario sur lequel vous travaillez.
Dans certaines circonstances, les procédures stockées présentent des avantages significatifs en termes de performances. Souvent, les requêtes générées par Linq et d'autres ORM peuvent être inefficaces, mais toujours assez bonnes pour vos besoins. Certains RBDMS (tels que SQL Server) mettent en cache les plans d'exécution des procédures stockées, ce qui permet d'économiser du temps de requête. Pour les requêtes plus complexes que vous utilisez fréquemment, ces économies de performances peuvent être critiques.
Pour la plupart des CRUD normaux, cependant, j'ai trouvé que c'est généralement mieux pour maintenabilité juste pour utiliser L'ORM s'il est disponible et si ses opérations répondent à vos besoins. Entity Framework fonctionne assez bien pour moi dans le monde.net la plupart du temps (en combinaison avec Linq), et j'aime beaucoup propulser pour PHP.
L'utilisation principale que je trouve pour eux est d'implémenter une couche d'abstraction et d'encapsuler la logique de requête. De la même manière que j'écris fonctions dans un langage procédural.
Je m'en tiens principalement à linq to sql en tant QU'ORM et je pense que c'est génial, mais il y a toujours une place pour les procédures stockées. Principalement, j'utilise le quand la requête que je veux exécuter est très complexe, avec beaucoup de jointures (en particulier les jointures externes, qui sucent dans Linq), beaucoup d'agrégation dans les sous-requêtes peut-être, les CTE récursifs, et d'autres scénarios similaires.
Pour le général crud cependant, il n'y a pas besoin.
Comme le mentionne le dorfier, l'une des principales raisons pour lesquelles sprocs (et/ou views) doivent être utilisés est de fournir une couche d'abstraction entre une base de données et ses clients (applications web, rapports, ETLs, etc.)
Cette 'API DB' peut faciliter la modification / refactorisation de votre base de données sans nécessairement affecter les clients.
Voir - Pourquoi utiliser stockées procs - pour une discussion plus approfondie