Quels sont les arguments contre ou pour mettre la logique d'application dans la couche de base de données?
[~ # ~] note [~ # ~] Le public de programmers.se et dba.se est différent et aura des points de vue différents, donc dans cette instance, je pense qu'il est valide de dupliquer Quels sont les arguments contre ou pour mettre la logique d'application dans la couche de base de données? on programmers.se.
Je n'ai pas pu trouver de discussion sur dba à ce sujet déjà, et le message original dit tout, donc:
La plupart des développeurs de logiciels souhaitent conserver la logique d'application dans la couche application, et il nous semble probablement naturel de la conserver ici. Les développeurs de bases de données semblent vouloir mettre la logique d'application dans la couche de base de données, en tant que déclencheurs et procédures stockées.
Personnellement, je préférerais garder autant que possible dans la couche application pour faciliter le débogage et séparer les responsabilités des couches.
Que pensez-vous de cela et qu'est-ce qui devrait ou ne devrait pas être mis en œuvre dans la couche de base de données?
N.B. Je ne suis pas l'OP pour cette question, mais j'ai laissé le libellé original intact.
Pensées variées ...
Votre code de base de données survivra à la technologie de votre client d'application. Pensez à ADO.NET -> Linq -> EF ainsi qu'à des ORM assortis. Alors que vous pouvez toujours exécuter le code SQL Server 2000 à partir de last millenium contre toutes les technologies clientes ci-dessus.
Vous avez également le problème des clients multiples: j'ai .net, Java et Excel. C'est 3 ensembles de logique d'application.
La "logique métier" ne doit pas être confondue avec la "logique d'intégrité des données". Si vous avez des clients qui commencent des transactions et effectuent des vérifications assorties, cela représente beaucoup d'appels de base de données et une longue transaction.
La logique d'application ne s'adapte pas aux volumes de données élevés. Nous avons 50k lignes par seconde en utilisant des procs stockés. Une équipe sœur utilisant Hibernate ne peut pas obtenir n par seconde
Je veux toute la logique qui doit s'appliquer à tous les utilisateurs et à toutes les applications de la base de données. C'est le seul endroit sensé pour le dire.
Le dernier Fortune 500 sur lequel je travaillais avait des applications écrites dans au moins 25 langues frappant leur base de données OLTP. Certains de ces programmes sont passés à la production dans les années 1970.
L'alternative à la mise en œuvre de ce type d'exigence dans la base de données consiste à laisser chaque programmeur d'application réimplémenter tout ou partie à 100% correctement, chaque fois qu'il lance son éditeur, du jour où il franchit la porte jusqu'à la fermeture de l'entreprise. Entreprise.
Quelles sont les chances?
N'est-ce pas le plus grand " ne vous répétez pas " de la planète?
Je déplace mon ancienne réponse sur non programmé de programmers.se, car les réponses semblent assez polarisées entre les sites.
Je sais que je suis dans un monde de mal ici, mais mettez la logique métier dans la base de données parce que:
- Vous pouvez autoriser les utilisateurs professionnels à accéder directement à la base de données et ne pas vous soucier de les visser (ou vous en soucier moins que vous ne le feriez avec une logique basée sur une application)
- Un utilisateur expérimenté peut créer de nouveaux rapports sans attendre une nouvelle version du logiciel.
- Vous pouvez tester SP/TRIGGER code dans une copie de la base de données, tout comme vous testez la logique basée sur une application
- Vous pouvez conserver le SQL pour créer des sp et des déclencheurs dans des fichiers texte (vous devriez quand même le faire pour le code table/vue)
- Vous pouvez mélanger et assortir des langues sans porter la logique métier
- Vous pouvez apporter des modifications à la logique métier sans mettre à niveau chaque bit de logiciel
- Vous auditez les changements de structure de la même manière que vous auditez l'activité de la base de données - via la journalisation
- Sécurité considérablement améliorée et contrôle d'accès à grain fin (la plupart des implémentations logiques basées sur les applications utilisent leur propre modèle de sécurité, de sorte que les données sont beaucoup plus faciles à compromettre. Le chiffrement réversible des mots de passe n'est pas rare)
- La sécurité des utilisateurs côté base de données réduit considérablement les dommages/vols indésirables que SQL peut faire
Les inconvénients sont les suivants: - Les développeurs sont menacés lorsque les utilisateurs deviennent moins dépendants des développeurs pour les rapports personnalisés - Les développeurs doivent apprendre un autre langage de programmation
Aucun de ces éléments ne devrait être important pour un développeur qualifié.
Il est intéressant de noter que la plupart des réponses parlent de "logique d'application" et non de "logique métier", comme si le logiciel n'était pas là pour fournir une fonction métier.
Le problème le plus important est de savoir si une "couche" au-dessus de la base de données pense qu'elle est propriétaire des données. La concurrence et l'intégrité des données sont des problèmes pour lesquels la solution est un SGBDR - certaines applications sont développées comme si la base de données n'était que leur ensemble de bits personnel et, bien sûr, elles finissent par essayer de réinventer la roue de toutes sortes de manières, ainsi que être irrémédiablement cassé dès qu'une autre application accède à la même base de données
J'ai écrit ma réponse à cela dans mon blog . Ma conclusion est, le faire dans l'application n'est tout simplement pas évolutif une fois que vous considérez le cycle de vie complet de l'application.
…
3. Ajoutez des contraintes d'intégrité/de vérification à la base de données sous-jacente, avec un code plus complexe implémenté dans le langage de procédure stockée de la base de données. De là, nous avons un emplacement central à maintenir et nous obtenons une application absolue des règles, même pour les applications que nous ne connaissons pas! Nous obtenons une langue pour exprimer les règles métier, tout au long du portefeuille d'applications et du cycle de vie, car la langue du jour change beaucoup plus souvent que la base de données. Et il fonctionne sur un système qui est déjà aussi critique que les applications les plus importantes. Les erreurs sont gérées par le code existant qui gère les erreurs de base de données dans ces applications. Il y a toujours le risque qu'une application se casse, bien sûr, mais des trois scénarios, c'est le moins, et seule l'application cassée a besoin d'une modification, pas tous (et la plupart des mécanismes SP/base de données permettront qu'une exception soit pour une seule application si cela est vraiment, vraiment nécessaire). Vous pensez que cela n'a pas d'importance dans votre nouveau site ou dans votre petite entreprise? Eh bien, si votre entreprise réussit, dans 30 ans, vous souhaiterez avoir prêté attention à ma sagesse!… Certaines [objections] j'entends souvent:
- Il est difficile de contrôler la version SP code déployé dans la base de données. Je ne pense pas que ce soit plus vrai que de dire que c'est difficile à contrôler les versions Java code déployé dans un serveur d'application, ce qui veut dire que ce n'est pas difficile du tout, c'est monnaie courante. Et sur Ruby-land, des livres entiers sont écrits à peu près comment faire passer votre code d'un environnement de développement en production, quelque chose qu'aucune autre communauté de langage ne semble avoir de difficulté. Pourtant, la version contrôlant une procédure stockée est apparemment trop difficile.
- Les procédures stockées sont difficiles à tester. C'est étrange. Pour commencer, les SP sont fortement typés; le compilateur vous dira s'il existe un chemin de code entrant ou sortant qui n'a pas de sens, et dans Oracle au moins, calculera toutes les dépendances pour vous. Il s'agit donc d'un ensemble de tests unitaires courants dont vous pourriez avoir besoin dans Ruby éliminé dès le départ. Pour tester OO le code nécessite une simulation pour contraindre l'objet à l'état interne) requis pour représenter le scénario de test - en quoi la configuration des données de test est-elle différente? Il existe un producteur TAP pour PL/SQL et d'autres outils. Il existe également des débogueurs et des profileurs.
- Un langage de procédure stockée n'est pas un langage complet. Eh bien, nous n'essayons pas d'écrire une application entière uniquement dans des procédures stockées! La plupart des langages dédiés SP ont toutes les constructions modernes que vous attendez, et dans Oracle au moins, vous pouvez utiliser Java Procédures stockées avec toutes les fonctionnalités du langage = OO les développeurs connaissent les procédures externes dans n'importe quel langage. Ce qui importe, c'est où la logique est implémentée - en un seul endroit, à proximité des données - le langage réel n'est qu'un détail. PL/SQL compile en code natif et s'exécute en cours avec la base de données; il n'y a pas d'architecture plus performante que cela.
- Je ne veux pas avoir à apprendre une autre langue. En négligeant une seconde, c'est un énorme drapeau rouge dans tout développeur (en particulier celui qui propose de modifier la production) applications qui pourraient être dans d'autres langues de toute façon!), il y a beaucoup à apprendre pour travailler dans n'importe quel environnement moderne: une boutique typique Java pourrait avoir Eclipse, WebLogic, Maven, Hudson, Anthill, Subversion, et une pléthore d'autres, que vous devez apprendre avant d'écrire une seule ligne de code d'application. Une connaissance pratique d'un très haut niveau SP langage est simple en comparaison, et il y aura plus de sans doute être un spécialiste ou un DBA pour vous aider aussi. Sans oublier que le développeur préféré Hibernate est livré avec son propre langage de requête…
…
Le SQL fait-il des choses comme la logique d'ensemble et le filtrage des résultats orienté application? SQL est un merveilleux langage de manipulation des ensembles.
De plus, comme GBN l'a indiqué ci-dessus, le code SQL va survivre presque universellement au code de l'application.
S'il est vrai que EF ou NHibernate ou LinqToSql ou quoi que ce soit vous permettra de générer du code plus rapidement, chaque programmeur digne de ses performances sait que seule l'optimisation du SQL optimisera la récupération des données. Le SGBDR ne comprend que SQL, vous devez donc tout transformer en SQL avant que tout soit dit et fait. (en supposant que nous pouvons convenir que TSQL et PLSQL sont toujours SQL)
Un inconvénient que les gens ne discutent pas nécessairement - les pros ont été épuisés ici - est le coût.
Les processeurs sur le serveur de base de données sont souvent les processeurs les plus chers de toute organisation pour faire face au coût de la licence de logiciel. Le passage de la logique métier au niveau des données doit donc être fait judicieusement, pas nécessairement de manière uniforme.
C'est là que la rencontre des esprits, c'est-à-dire les esprits des développeurs (DV) et des DBA, doit inévitablement se produire. Travailler avec Business Logic (BL) et les stocker dans une base de données peut avoir un impact qui peut glorifier ou horrifier sa mise en œuvre.
Pour certains produits SGBDR, il existe des bibliothèques/outils/API supérieurs pour la logique métier et les infrastructures d'objets que l'on pourrait rapidement apprendre et utiliser dans leurs applications. Pour les autres SGBDR, aucune bibliothèque/outils/API n'existe.
Dans le passé, les applications client-serveur faisaient le pont vers BL via les procédures stockées (SP). Pour des produits comme Oracle et SQL Server, cela a été fait tôt. Au fur et à mesure de la création de bases de données open source telles que PostgreSQL et MySQL, ceux qui les utilisaient risquaient de percer de nouveaux horizons avec les procédures stockées dans BL. PostgreSQL a évolué très rapidement dans ce domaine, car non seulement les procédures stockées ont été implémentées, mais également la possibilité de créer des langages client est également apparue. MySQL a fondamentalement cessé d'évoluer dans le monde des procédures stockées et est venu sous une forme allégée d'un langage avec de nombreuses restrictions. Ainsi, en ce qui concerne BL, vous êtes complètement à la merci de MySQL et de son langage de procédure stockée.
Il ne reste qu'une question: quel que soit le SGBDR, BL doit-il résider en tout ou en partie dans la base de données?
Pensez au développeur. Lorsque les choses tournent mal dans une application, le processus de débogage fait entrer et sortir le développeur d'une base de données pour suivre les modifications de données qui peuvent ou non être correctes par intermittence. C'est comme coder une application C++ et appeler du code Assembler au milieu. Vous devez passer du code source, des classes et des structures aux interruptions, registres et décalages ET RETOUR !!! Cela prend le débogage au même niveau.
Les développeurs peuvent être en mesure d'élaborer une méthode rapide d'exécution de BL en conjonction avec des configurations de langage (drapeaux de compilateur pour C++, différents paramètres pour PHP/Python, etc.) via des objets métier assis en mémoire plutôt que dans une base de données. Certains ont essayé de relier cette idéologie pour un code d'exécution plus rapide dans la base de données en écrivant des bibliothèques où le débogage des procédures stockées et des déclencheurs est bien intégré dans la base de données et semble utilisable à l'infini.
Ainsi, le développeur est mis au défi de développer, déboguer et maintenir le code source et BL dans deux langages.
Pensez maintenant au DBA. Le DBA veut garder la base de données allégée et signifier autant que possible dans le domaine des procédures stockées. Le DBA peut voir BL comme quelque chose d'extérieur à la base de données. Pourtant, lorsque SQL appelle les données nécessaires pour BL, le SQL doit être maigre et méchant.
Maintenant, pour la rencontre des esprits !!!
Code développeur SP et utilise des méthodes itératives. DBA examine le SP. DBA détermine qu'une seule instruction SQL peut remplacer les méthodes itératives écrites par le développeur. Le développeur voit que l'instruction SQL suggérée par le DBA nécessite appeler un autre code BL ou SQL qui ne suit pas les plans d'exécution normaux de l'instruction SQL.
À la lumière de cela, la configuration, l'optimisation des performances et le codage SP deviennent une fonction de la profondeur et de l'intensité des données du BL pour la récupération des données. Plus le BL est profond et intensif, plus plus de développeurs et DBA doivent être sur la même page pour la quantité de données et la puissance de traitement donnée à la base de données.
CONCLUSION
La manière de récupérer les données doit toujours impliquer les développeurs et les camps DBA. Il faut toujours faire des concessions quant aux méthodes de codage et aux paradigmes de récupération de données qui peuvent fonctionner ensemble, à la fois pour la vitesse et pour l'efficacité. Si la préparation des données pour le code source à gérer n'est effectuée qu'une seule fois avant que le code n'obtienne les données, le DBA doit dicter l'utilisation du SQL maigre et moyen. Si le BL est quelque chose avec lequel le DBA n'est pas en phase, les rênes sont alors entre les mains du développeur. C'est pourquoi le DBA doit se voir et faire partie de l'équipe de projet et non une île pour lui-même, tandis que le développeur doit laisser le DBA effectuer le réglage fin du SQL s'il le justifie.
C'est une belle question à poser sur un site Web plein de DBA. Espérons que la plupart des réponses seront "pro" pour maintenir la base de données dans un état ACID, et donc conserver la logique métier dans la base de données. : -)
Quant à mon avis, je pense que vous devriez implémenter la logique métier à la fois dans vos applications et vos bases de données. Cette approche coûtera plus de temps et d'argent, mais je pense qu'elle aura une meilleure solution commerciale qualitative.
Comme Adam Musch l'a dit ci-dessus, il y a plus à considérer ici pour la performance. L'utilisation du processeur. Utilisation de la mémoire.
Empêchez évidemment les mauvaises choses d'accéder à la base de données.
- Éliminez les adresses e-mail qui ne sont pas conformes de manière élémentaire.
- Vérifier les longueurs
Lorsque vous approfondissez, c'est là que des décisions doivent être prises. Le serveur DB est un endroit très coûteux pour faire des choses que le client pourrait faire facilement. exemple: formatage des données, formatage des dates, assemblage de chaînes, etc. côté client.
Faites-vous le calcul/traitement sur le client ou sur le serveur DB? Pour moi, cela dépend de la complexité et du nombre d'enregistrements impliqués. La logique métier doit vraiment être effectuée dans la base de données elle-même afin que tout soit traité de la même manière.
Vous devez vraiment créer une API de vues à lire et des procs stockés pour écrire les données dans la base de données pour vous éviter des maux de tête à l'avenir.
Utilisez les forces de chaque extrémité à votre avantage.