Contrairement au code de langage de programmation réel, ils :
- non portable (chaque base de données a sa propre version de PL/SQL. Parfois différentes versions du même base de données sont incompatibles - je l'ai vu !)
- pas facilement testable - vous avez besoin d'un vrai (dev) instance de base de données pour les tester et donc tester unitairement leur code dans le cadre d'une construction est pratiquement impossible
- pas facilement modifiables/publiables - vous devez les supprimer/créer, c'est-à-dire modifier la base de données de production pour les libérer
- n'ont pas de support de bibliothèque (pourquoi écrire du code quand quelqu'un d'autre l'a)
- ne sont pas facilement intégrables avec d'autres technologies (essayez d'appeler un service Web depuis celles-ci)
- ils utilisent un langage à peu près aussi primitif que Fortran et sont donc inélégants et laborieux pour obtenir un codage utile, il est donc difficile d'exprimer une logique métier, même si c'est généralement leur objectif principal
- ne propose pas de débogage/traçage/journalisation des messages, etc. (certaines bases de données peuvent prendre en charge cela - je ne l'ai pas vu cependant)
- manque d'un IDE décent pour aider avec la syntaxe et les liens vers d'autres procédures existantes (par exemple, comme le fait Eclipse pour Java)
- les personnes compétentes pour les coder sont plus rares et plus chères que les codeurs d'applications
- leurs "hautes performances" sont un mythe, car elles s'exécutent sur le serveur de base de données qu'elles augmentent généralement la charge du serveur de base de données, donc leur utilisation réduira généralement votre débit de transaction maximal
- incapacité à partager efficacement les constantes (normalement résolue en créant une table et en l'interrogeant 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 dans la transaction pour maintenir l'intégrité de la base de données) ou si vous gardez vos procédures très atomiques et simples, vous pourriez peut-être les envisager.
La prudence est recommandée lors de la spécification "haute performance" à l'avant. Cela conduit souvent à de mauvais choix au détriment d'une bonne conception et cela vous mordra beaucoup plus tôt que vous ne le pensez.
Utilisez les procédures stockées à vos risques et périls (de la part de quelqu'un qui y est allé et ne veut plus jamais y retourner). Ma recommandation est de les éviter comme la peste.
