web-dev-qa-db-fra.com

Avantages et inconvénients de conserver toute la logique métier dans les procédures stockées dans l'application Web

Dans certaines organisations, j'ai travaillé pour des applications Web développées en basant toute la logique métier dans les procédures stockées de la base de données. Par exemple, utilisez html pour la vue et le servlet en tant que contrôleurs pour détourner la demande du client vers les procédures stockées de la base de données appropriées.

Quels sont les avantages et les inconvénients de ce type de conceptions? À mon avis, si la logique métier dépend fortement de la base de données, il vaut mieux suivre ce type de conception !!!!!

designweb-applicationsstored-procedures
40
droidsites

En théorie, les avantages et les inconvénients sont les suivants:

Avantages:

  1. Un seul endroit pour contenir toute la logique métier
  2. Applications probablement plus rapides car plusieurs requêtes SQL et autres peuvent être effectuées en un seul "aller-retour" vers la base de données
  3. Trivial pour utiliser les procédures stockées de plusieurs applications

Les inconvénients:

  1. Un DBA sera nécessaire pour le réglage des performances
  2. Tous les développeurs devront être très bien familiarisés avec votre dialecte SQL particulier (T-SQL, Pl/SQL, etc.)
  3. Le code SQL n'est pas aussi expressif et donc plus difficile à écrire lorsqu'il couvre des concepts de niveau supérieur qui ne sont pas vraiment liés aux données
  4. Une charge beaucoup plus inutile sur la base de données

Maintenant, pratiquement, seul un idiot aurait toute la logique métier dans la base de données.

  1. Très peu de développeurs seront en mesure de créer une interface de procédure stockée cohérente qui fonctionne facilement entre les applications. Habituellement, cela est dû au fait que certaines hypothèses sont faites pour cette application appelante.
  2. Il en va de même pour la documentation de toutes ces procédures stockées
  3. Les serveurs de base de données sont généralement suffisamment goulots d'étranglement. Leur imposer une charge inutile réduit encore plus ce goulot d'étranglement. Un équilibrage de charge complexe et un matériel costaud seront nécessaires pour tout ce qui a un volume de trafic décent
  4. SQL est à peine un langage de programmation. J'ai eu le plaisir de maintenir un moteur de script écrit en tant que procédure stockée T-SQL. Il a été lent, presque impossible à comprendre et a mis des jours à mettre en œuvre ce qui aurait été une extension triviale dans la plupart des langues.
  5. Que se passe-t-il lorsqu'un client a besoin de sa base de données pour exécuter un autre serveur SQL? Vous devrez essentiellement recommencer à zéro - Vous êtes très lié à votre base de données. Il en va de même lorsque Microsoft décide de déprécier quelques fonctions que vous utilisez quelques centaines de fois dans vos procédures stockées
  6. Le contrôle des sources est extrêmement difficile à faire correctement avec les procédures stockées, d'autant plus lorsque vous en avez beaucoup
  7. Les bases de données sont difficiles à maintenir synchronisées. Qu'en est-il lorsque vous avez un conflit quelconque entre 2 développeurs qui travaillent dans la base de données en même temps? Ils écraseront le code de l'autre sans vraiment le savoir, en fonction de la configuration de votre "base de données de développement"
  8. Les outils sont certainement moins faciles à utiliser, quel que soit le moteur de base de données que vous utilisez.

Donc, pour répondre objectivement à la question. Dans la plupart des cas, les procédures stockées ne sont nécessaires que dans certains cas. Par exemple, si vous avez un rapport à générer là où vous devez effectuer un grand nombre de traitements conditionnels sur quelques grandes tables, vous ne voudriez pas que votre application effectue quelques centaines de requêtes SQL dans la base de données. Vous souhaitez créer une procédure stockée afin de ne pas avoir de surcharge de décalage réseau. De plus, vous ne souhaiterez généralement créer des procédures stockées que dans le cas où les clients souhaitent exécuter une requête personnalisée dans votre base de données. Les procédures et les vues stockées peuvent rendre cela facilement possible sans que vos clients soient des experts en bases de données.

62
Earlz

Contre:

  • La base de données est la partie la moins évolutive de votre architecture,
  • Surtout à l'ère des services Web et des applications Web tierces REST-ful, vous ne pourrez pas contenir toute votre logique métier dans des processus stockés.
  • Les implémentations SQL varient, certaines peuvent être délicates et aucune ne se lit aussi facilement qu'un langage de programmation de couche application de première classe.
    • N'oubliez pas que le code est lu beaucoup plus souvent qu'il n'est écrit .
16
Jim G.

Avantages de conserver toute la logique métier sur les procédures stockées dans l'application Web pour:

  • Un seul endroit est plus facile à entretenir que plusieurs
  • Les bases de données sont rapides et optimisées et peuvent être bien dimensionnées.
  • Les mêmes procédures peuvent être appelées à partir de plusieurs cadres et langages différents.
  • La logique est découplée de l'implémentation dans des applications particulières.
  • La reprise peut être réduite pour les applications changeantes lorsque la base de données reste la même.

Contre de tenir toute la logique métier sur les procédures stockées dans l'application web: contre:

  • De bonnes connaissances SQL peuvent être difficiles à trouver dans de nombreux endroits.
  • De bons codeurs SQL peuvent coûter cher.
  • Tous les développeurs d'applications devront pouvoir la modifier ou demander une modification rapide.
  • Certaines données qui sont moins bien adaptées à une base de données SQL, par exemple les données d'image ou les données de document peuvent ne pas être disponibles dans la base de données et il peut être difficile de les intégrer aux procédures stockées.
9
Michael Durrant

Il y a 2 gros inconvénients que je rencontre habituellement:

  1. Incapacité à tester à l'unité vos procédures stockées. Bien sûr, il existe des cadres de tests unitaires, mais vous rencontrez généralement des problèmes d'exécution de plus d'un jeu de tests à la fois (problèmes de concurrence et de transaction).
  2. La plupart des entreprises voudront mettre beaucoup de connexion dans les proc stockés, mais embaucher ensuite 5 fois plus de programmeurs d'application (que ce soit C #, Ruby, Java, peu importe) que les programmeurs de base de données ou les DBA, et pour une raison quelconque, attendez-vous à ce que tous leurs codeurs d'application comprendre et être capable d'écrire des procédures de base de données performantes et évolutives (en PL/SQL, T-SQL ou autre). La direction ne se rend généralement pas compte que cela revient à embaucher un expert C # pour vous écrire du code Python, et se demander pourquoi ils n'écrivent pas des applications incroyables.
7
rally25rs

Ça dépend

Tout dépend de votre team's experience et ton project's requirements. Apportez un DBA à votre équipe et décidez de ce que vous devez faire pour répondre aux exigences.Cependant, avec la conception d'applications à plusieurs niveaux, il peut ne pas être la bonne décision d'encapsuler la logique métier dans une procédure stockée.

Peu importe

Tant que la logique métier:

  • vit au même endroit
  • où il est correctement documenté
  • un accès approprié est fourni par le biais de services qui peuvent être couplés de manière lâche
  • via une interface abstraite publiée

Je pense que business logic in programming space makes more sense quand Power of Expression est important dans votre équipe/projet.

Je pense que l'espace SQL n'est pas aussi expressif, mais it can do the job. Utilisez les meilleurs outils que vous avez sous la main pour les tâches les plus appropriées. Il est préférable de jouer avec la logique et les concepts d'ordre supérieur au highest level. Par conséquent, le stockage et la manipulation des données de masse sont mieux effectués au niveau du serveur, probablement dans les procédures stockées.

6
Yusubov

À l'ère moderne, ce n'est plus vraiment une approche courante. Il fut un temps où mettre la logique métier dans les procédures stockées était une chose courante à faire au début de la programmation Web, car les alternatives étaient peu nombreuses et souvent difficiles à utiliser. Aujourd'hui, je recommanderais contre.

Je dois dire qu'en 2012, rien dans la logique métier dans les procédures stockées ne pouvait être justifié comme un choix ayant en quelque sorte battu d'autres approches après avoir pesé le pour et le contre. Tout point PRO serait au mieux académique.

Ce n'est pas du code linq. L'avenir de TSQL est compilé linq, le mien aussi commence à l'apprendre.

Le code compilé est plus stable et plus facile à utiliser. Si je débogue quelque chose, il y a tellement d'informations disponibles si j'utilise C # ou Java.

Les procédures stockées risquent de se retrouver avec trop de responsabilités, il est préférable d'essayer de limiter vos responsabilités à 1.

Le manque de séparation des responsabilités conduira à une application qui devient de plus en plus difficile à travailler et de moins en moins stable car ses classes de base deviennent de plus en plus grandes.

Si vous aimez Microsoft Asp.Net MVC combiné avec Entity Framework Code First vous permettra de créer rapidement n'importe quelle application et vous n'aurez pas besoin de procédures stockées.

3
Honorable Chow