Quelqu'un peut-il dire les procédures stockées pour et contre ET les Procédures stockées Java pour et contre?

Les arguments pour et contre les procédures stockées ont tendance à se diviser sur ce que vous pensez être la bonne réponse à la question: la logique métier appartient-elle à la base de données ou à l'application? Je vais essayer d'être neutre dans ma présentation des arguments. Si je réussis, certains de mes avantages et inconvénients se contrediront.

PRO

1. Les procédures stockées facilitent le partage du code de base de données entre les applications
2. La logique de co-localisation des données avec les données le rend facile à appliquer les règles métier à travers les applications. Cette approche privilégie le propriétaire des données sur l'utilisateur des données.
3. Les procédures stockées utilisent un langage adapté à la programmation de base de données.
4. Les procédures stockées évoluent avec la base de données.

CON

1. La logique métier n'appartient pas à la base de données.
2. Les procédures stockées sont écrites dans des langages de programmation spécialisés et maladroits que le développeur moyen n'a aucun intérêt à apprendre.
3. Nous impossible de demander au DBA d'écrire des procédures stockées car les DBA détestent les développeurs.
4. Les procédures stockées s'exécutent dans la base de données et la base de données est le goulot d'étranglement.

Beaucoup de ces points généraux s'appliquent également aux procédures stockées Java. J'ai écrit une réponse à votre question connexe , donc ces avantages et inconvénients peuvent sembler familiers.

PRO

1. Les procédures stockées Java nous permettent d'étendre les fonctionnalités accessibles aux programmes de base de données.
2. Dans en particulier, il peut nous permettre une plus grande flexibilité pour intégrer les opérations dans la base de données et les domaines du système d'exploitation.
3. Beaucoup de développeurs savent écrire Java.
4. Les procédures stockées Java nous permettent de déployer notre application de base de données sur différents produits SGBD.

CON

1. Java ne fonctionne pas aussi bien que le code de base de données natif.
2. Les procédures stockées Java impliquent l'écriture de code sur mesure qui duplique les fonctionnalités intégrées..
3. Java n'est pas adapté aux opérations de base de données.
4. Java peut poser des problèmes de sécurité. surtout quand il s'agit d'exécuter des programmes sur le système d'exploitation à partir de la base de données.

Ce qui suit est vrai pour les procédures stockées natives et les procédures stockées Java: le code écrit par des développeurs ne comprenant pas le fonctionnement des bases de données peut très mal fonctionner vraiment. Cela s'applique également aux frontaux construits ou aux outils ORM configurés sans le niveau d'expertise approprié. Cependant, cette situation est moins susceptibles de se produire avec les procédures stockées natives parce que leur fonctionnalité est façonnée vers la création d'applications de base de données efficaces.

Procédures Stockées pro:

-Sécurisé

-Performances et évolutivité

-Permet de modifier un niveau (la base de données elle-même plutôt que le code réel du interface/page web)

- Peut être scripté ou déplacé facilement