Quels sont les arguments contre ou pour mettre la logique d'application dans la couche base de données?

NOTE L'audience de programmers.se et de dba.se est différente et aura des points de vue différents. Par conséquent, dans ce cas, je pense qu'il est correct de dupliquer. Quels sont les arguments pour ou pour placer la logique d'application dans la couche base de données? sur programmers.se.

Je n'ai pas encore trouvé de discussion sur dba à ce sujet, et le post original dit tout, donc:

La plupart des développeurs de logiciels souhaitent conserver la logique de l'application dans la couche application, ce qui nous semble probablement naturel. Les développeurs de bases de données semblent vouloir placer la logique de l'application dans la couche 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 d'application pour faciliter le débogage et maintenir les responsabilités des couches séparées.

Que pensez-vous de cela et que devrait ou ne devrait pas être implémenté dans la couche base de données?

NB: je ne suis pas le PO pour cette question, mais j'ai laissé le libellé original intact.

Pensées assorties ...

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. Considérant que vous pouvez toujours exécuter le code SQL Server 2000 du dernier millénaire contre toutes les technologies client ci-dessus.

Vous avez également le problème de client multiple: 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 à une base de données et une transaction longue.

La logique d'application ne s'adapte pas aux volumes de données élevés. Nous avons 50k lignes par seconde en utilisant les procs stockés. Une équipe soeur utilisant Hibernate ne peut en obtenir un 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 raisonnable pour le dire.

Lors du dernier Fortune 500 où j'ai travaillé, des applications écrites dans au moins 25 langues ont été enregistrées dans leur base de données OLTP. Certains de ces programmes sont passés à la production dans les années 1970.

L’alternative à l’implémentation de ce type d’exigences dans la base de données est de laisser chaque programmeur d’application le réimplémenter correctement, en tout ou en partie, chaque fois qu’il lance son éditeur, du jour où ils franchissent la porte jusqu’à ce que la société cesse de fonctionner. Entreprise.

Quelles sont les chances?

N'est-ce pas le plus gros " ne te répète pas " sur la planète?

Je déplace mon ancienne réponse de non programmée à programmers.se, car les réponses semblent assez polarisées entre les sites.

Je sais que je vais me trouver dans un monde de blessures, mais insérez la logique commerciale dans la base de données car:

• Vous pouvez autoriser les utilisateurs professionnels puissants à accéder directement à la base de données sans avoir à s'inquiéter de tout perdre (ou moins avec la logique basée sur les applications).
• Un utilisateur expérimenté peut créer de nouveaux rapports sans attendre une nouvelle version du logiciel.
• Vous pouvez tester le code SP / TRIGGER dans une copie de la base de données, tout comme vous testez la logique basée sur les applications.
• Vous pouvez conserver le code SQL pour créer des sp et des triggers dans des fichiers texte (vous devriez le faire de toute façon pour le code table / vue)
• Vous pouvez mélanger et assortir des langues sans porter la logique métier
• Vous pouvez modifier la logique métier sans mettre à niveau tous les logiciels.
• Votre structure d'audit change de la même manière que l'audit de l'activité de la base de données - via la journalisation.
• Sécurité considérablement améliorée et contrôle d'accès plus fin (la plupart des implémentations logiques basées sur des applications utilisent leur propre modèle de sécurité, de sorte que les données sont beaucoup plus faciles à compromettre. Le cryptage de mot de passe réversible n'est pas rare)
• La sécurité des utilisateurs côté base de données réduit considérablement les dégâts / vols que SQL peut causer

Les inconvénients sont les suivants: - Les développeurs sont menacés lorsque les utilisateurs dépendent moins des développeurs pour obtenir des rapports personnalisés - Les développeurs doivent apprendre un autre langage de programmation

Aucun de ceux-ci ne devrait compter pour un développeur expérimenté.

Il est intéressant de noter que la plupart des réponses parlent de «logique d'application» et non de «logique d'entreprise», comme si le logiciel n'était pas là pour fournir une fonction commerciale.

La question la plus importante est de savoir si une "couche" au-dessus de la base de données pense qu'elle est propriétaire des données. La simultanéité 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 sachet de bits personnel et bien sûr, elles finissaient par essayer de réinventer la roue de toutes sortes de façons, ê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 que le fait de le faire dans l’application n’évolue pas une fois que vous considérez le cycle de vie complet de l’application.

…
3. Ajoutez des contraintes d'intégrité / 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. À partir de cela, nous avons un emplacement central à maintenir et nous obtenons une application absolue des règles, même pour des applications que nous ne connaissons pas! Nous utilisons une seule langue pour exprimer les règles métier dans l'ensemble 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 un risque qu'une application se casse bien sûr, mais parmi les trois scénarios, c'est le moins, et seule l'application endommagée doit être modifiée, pas tous (et la plupart des mécanismes SP / base de données permettent une exception pour une application si cela est vraiment, vraiment nécessaire). Vous pensez que cela n'a pas d'importance dans votre site ou votre petite entreprise? Eh bien, si votre entreprise réussit, dans 30 ans, vous souhaiteriez avoir prêté attention à ma sagesse!

… Quelques [objections] j'entends souvent:

• Il est difficile de contrôler le code de version SP utilisé dans la base de données. Je ne pense pas que ce soit plus vrai que de dire qu'il est difficile de contrôler le code Java déployé dans un serveur d'applications, ce qui veut dire que ce n'est pas difficile du tout, c'est courant. Et dans Ruby-land, des livres entiers sont écrits sur la façon de passer votre code d’un environnement de développement à la production, une chose avec laquelle aucune autre communauté linguistique ne semble se débattre. Pourtant, la version contrôlant une procédure stockée est apparemment trop difficile.
• Les procédures stockées sont difficiles à tester. Ceci est un étrange. Pour commencer, les SP sont fortement typés; le compilateur vous dira s'il y a un chemin d'accès au code qui n'a pas de sens et, du moins dans Oracle, calculera toutes les dépendances pour vous. Voilà donc un ensemble de tests unitaires communs dont vous pourriez avoir besoin en Ruby et éliminés immédiatement. Pour tester le code OO, vous devez vous moquer 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 également un producteur de TAP pour PL / SQL et d'autres outils. Il y a aussi des débogueurs et des profileurs.
• Une langue de procédure stockée n'est pas une langue complète. Eh bien, nous n'essayons pas d'écrire une application complète uniquement dans des procédures stockées! La plupart des langages SP dédiés ont toutes les constructions modernes que vous attendez et, dans Oracle au moins, vous pouvez utiliser les procédures stockées Java avec toutes les fonctionnalités de langage connues des développeurs OO, ou des procédures externes dans n'importe quel langage. Ce qui compte, c’est lorsque la logique est mise en œuvre - à un endroit proche des données - le langage réel n’est qu’un détail. PL / SQL se compile en code natif et s'exécute en processus avec la base de données; il n'y a pas d'architecture plus performante que celle.
• Je ne veux pas avoir à apprendre une autre langue. En oubliant une seconde, cela est un énorme drapeau rouge pour tout développeur (en particulier pour celui qui propose de modifier les applications de production qui pourraient être de toute façon dans d'autres langues!), Il y a beaucoup à apprendre à travailler dans n'importe quel environnement moderne: un magasin Java typique pourrait avoir Eclipse , WebLogic, Maven, Hudson, Anthill, Subversion et une multitude d’autres, que vous devez apprendre avant d’écrire une seule ligne de code d’application. Une connaissance pratique d'un langage SP de très haut niveau est simple en comparaison, et il y aura plus que probablement un spécialiste ou un DBA pour vous aider aussi. Sans compter que le développeur préféré de Hibernate est livré avec son propre langage de requête…

…

Est-ce que le SQL fait des choses comme définir la logique et filtrer les résultats en fonction des applications? SQL est un merveilleux langage de manipulation d'ensembles.

En outre, comme l'a souligné GBN ci-dessus, le code SQL survivra presque universellement au code de l'application.

S'il est vrai que EF ou NHibernate ou LinqToSql vous permettront de générer du code plus rapidement, chaque programmeur digne de ce nom sait que seule l'optimisation du code SQL optimisera la récupération des données. Le SGBDR ne comprend que le SQL, vous devez donc tout transformer en SQL avant que tout soit dit et fait. (en supposant que nous puissions convenir que TSQL et PLSQL sont toujours du SQL)

Un inconvénient dont les gens ne discutent pas nécessairement - les avantages 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 coûteux de toutes les organisations lorsqu’ils calculent le coût des licences logicielles. Le transfert de la logique métier vers le niveau de données doit donc être effectué de manière judicieuse, pas nécessairement de manière uniforme.

C'est ici que la rencontre des esprits, c'est-à-dire des esprits des développeurs et des administrateurs de bases de données, doit inévitablement se produire. L'utilisation de Business Logic (BL) et le stockage de ce type dans une base de données peuvent avoir un impact qui peut glorifier ou horrifier sa mise en œuvre.

Pour certains produits de SGBDR, il existe des bibliothèques / outils / API de qualité supérieure pour la logique d'entreprise et les infrastructures d'objet que l'on pourrait rapidement apprendre et utiliser dans leurs applications. Pour les autres SGBDR, il n’existe pas de bibliothèques / outils / API.

Auparavant, les applications client / serveur établissaient le pont en BL via les procédures stockées (SP). Pour des produits tels qu'Oracle et SQL Server, cela a été fait tôt. Lorsque des bases de données open source telles que PostgreSQL et MySQL ont été créées, ceux qui les utilisaient risquaient d'innover avec les procédures stockées dans BL. PostgreSQL a mûri très rapidement dans ce domaine, car non seulement des procédures stockées ont été mises en œuvre, mais également la possibilité de créer des langages client. MySQL a pratiquement cessé d'évoluer dans le monde des procédures stockées et est apparu sous la forme d'un langage simplifié avec de nombreuses restrictions. Ainsi, quand il s'agit de BL, vous êtes complètement à la merci de MySQL et de son langage de procédure stockée.

Il ne reste en réalité qu'une seule question: quel que soit le SGBDR, le 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 oblige le développeur à entrer et à sortir 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 basculer du code source, des classes et des structures vers des interruptions, des registres et des décalages AND BACK !!! Cette prise de débogage à ce même niveau.

Les développeurs peuvent peut-être concevoir une méthode d’exécution à grande vitesse de BL en conjonction avec des configurations de langage (drapeaux de compilation pour C ++, différents paramètres pour PHP / Python, etc.) via des objets métier conservés 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 dans lesquelles le débogage des procédures stockées et des déclencheurs est bien intégré à la base de données et apparemment utilisable.

Ainsi, le développeur est mis au défi de développer, de déboguer et de maintenir le code source et le BL dans deux langues.

Maintenant, pensez à la DBA. L'administrateur de base de données souhaite que la base de données reste la plus légère possible dans les procédures stockées. L'administrateur de base de données peut voir dans BL un élément externe à la base de données. Pourtant, lorsque SQL appelle les données nécessaires pour BL, le SQL doit être simple et efficace.

Maintenant, pour la rencontre des esprits !!!

Le développeur code les SP et utilise les méthodes iteractive. DBA regarde le SP. DBA détermine qu'une seule instruction SQL peut remplacer les méthodes iteractive écrites par le développeur. Le développeur voit que l'instruction SQL suggérée par le DBA nécessite l'appel d'un autre code lié au BL ou à un SQL qui ne suit pas les plans d'exécution normaux de l'instruction SQL.

À la lumière de cela, la configuration, le réglage des performances et le codage SP deviennent une fonction de la profondeur et de l'intensité des données de BL pour la récupération des données. Plus le BL est profond et approfondi, plus il doit y avoir de développeurs et d'administrateurs de base de données sur la même page en ce qui concerne la quantité de données et la puissance de traitement attribuées à la base de données.

CONCLUSION

Le mode de récupération des données doit toujours impliquer les camps de développeur et de DBA. Des concessions doivent toujours être faites quant aux méthodes de codage et aux paradigmes d'extraction de données qui peuvent fonctionner ensemble, pour une vitesse et une efficacité optimales. Si la préparation des données à manipuler par le code source n’est effectuée qu’une fois avant que le code n’obtienne les données, le DBA doit dicter l’utilisation du code SQL simplifié et moyen. Si le BL est quelque chose avec lequel le DBA n'est pas en accord, les rênes sont alors entre les mains du développeur. C'est pourquoi l'administrateur de base de données doit se voir et faire partie de l'équipe de projet et non pas une île pour lui-même, tandis que le développeur doit laisser à l'administrateur de base de données le soin de peaufiner le code SQL s'il le justifie.

C'est une bonne question à poser sur un site web rempli de DBA. Espérons que la plupart des réponses seront "pro" en faveur du maintien de la base de données dans un état ACID, et donc de la logique métier dans la base de données. :-)

En ce qui concerne mon opinion, je pense que vous devriez implémenter la logique métier 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 ainsi une meilleure solution commerciale qualitative.

Comme Adam Musch l'a dit plus haut, il y a plus à considérer ici pour la performance. L'utilisation du processeur. Utilisation de la mémoire.

Bloquez évidemment les mauvaises choses pour accéder à la base de données.

• Éliminez les adresses e-mail qui ne sont pas conformes de manière générale.
• Vérifier les longueurs

Lorsque vous approfondissez, vous devez prendre des décisions. Le serveur de base de données est un endroit très coûteux pour effectuer des tâches que le client pourrait facilement faire. exemple: formatage des données, formatage des dates, assemblage des chaînes, etc. côté client.

Est-ce que vous faites le calcul / le traitement chez le client ou sur le serveur de base de données? Pour moi, cela dépend de la complexité et du nombre d'enregistrements impliqués. La logique métier doit vraiment être réalisée dans la base de données afin que tout soit traité de la même manière.
Vous devez vraiment créer une API de vues pour lire et stocker les procs pour écrire les données dans la base de données afin de vous éviter des maux de tête à l'avenir.

Utilisez les forces de chaque extrémité à votre avantage.