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

45

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?

Modifier Cette question est également traitée dans dba.se , du point de vue des administrateurs de base de données. Comme programmers.se et dba.se ont des publics et des préjugés différents, les futurs lecteurs voudront peut-être examiner les deux ensembles de réponses avant de décider ce qui leur convient le mieux.

Vetle
la source
13
Je serais également intéressé de savoir si des partisans de la logique d'application dans la couche base de données peuvent fournir des méthodes de test unitaire de cette logique d'application.
Chris Buckett
@ChrisB: pour Oracle, il y a plunit.com/index.htm
Tony Andrews le
10
Logique d’entreprise, pas de logique d’application - l’objectif devrait être le domaine du problème, pas le choix de la technologie!
Phil Lello
1
@ChrisB: Je parie qu'ils peuvent le faire - peupler les tables avec des données (vous devez créer des classes fictives dans le calque de l'application), puis appeler le SP automatiquement avec un script. Le tout peut être écrit comme un script d'instructions SQL, le nettoyage et la configuration au fur et à mesure. Voici un lien pour les outils SQL de test de 3 unités: toadworld.com/BLOGS/tabid/67/EntryId/67/…
gbjbaanb
J'ai récemment écrit mes réflexions à ce sujet sur mon blog
Gaius

Réponses:

38

Les avantages de mettre de la logique dans la couche application me viennent à l’esprit .

  1. Testabilité . Cela devrait être une raison suffisante en soi.
  2. Meilleure structure de code . Il est très difficile de suivre une architecture OO appropriée avec SQL. Cela facilite également la maintenance du code.
  3. Plus facile à coder . En raison des différentes fonctionnalités linguistiques disponibles dans la langue que vous utilisez, il est généralement plus facile de coder dans la couche d'application.
  4. Réutilisation de code . Il est beaucoup plus facile de partager du code avec des bibliothèques que de partager du code dans la base de données.
Jaco Pretorius
la source
5
Pouvons-nous également ajouter la possibilité de contrôler les objets au fur et à mesure qu'ils sont modifiés? Peut-être que c'est juste mon problème personnel ... (oui, je suis évidemment en
train d'
6
Re: 4. Génial! Utilisons cette logique VB dans mon application Java Solaris ... oh, accrochez-vous ...
Phil Lello
11
Phil, génial! Utilisons votre logique Oracle dans mon application SQL Server ... oh, accrochez-vous ...
Craig
9
@Craig En réalité, les entreprises changent de fournisseur de base de données beaucoup moins souvent que de changer d'application ou de langue. Cependant, mon point de vue était plus que ce n'est pas un avantage de app vs db, pas que db est supérieur ici; il y a des avantages et des inconvénients pour l'une ou l'autre approche
Phil Lello
1
@jcolebrand - Eh bien, si vous développez une base de données , VS 2010 est la bombe. Je suis en train de faire passer notre groupe de SSMS à VS pour le travail de développement et envisage d'adopter cette solution TDD qui fait fureur chez les développeurs. C'est un investissement de temps rentable pour tout magasin avec un travail de développement de base de données important (et une tendance vers SQL Server, bien sûr).
Nick Chammas
11

Bien qu'il soit possible d'utiliser le contrôle de version avec des procédures stockées (par exemple, les outils de base de données Redgate s'intègrent à TFS), ce n'est pas toujours aussi simple qu'avec le code d'application.

Ma position par défaut est que la logique devrait rester en dehors de la couche base de données, cependant, il serait parfois plus efficace de mettre en œuvre la logique dans la base de données. Si tel est le cas, vous devez vous assurer que vous pouvez suivre les modifications apportées à ce code.

ChrisF
la source
4
"pas aussi simple qu'avec le code d'application" pourquoi pas?
NimChimpsky
@Nim - à moins que je ne le fasse mal, cela implique des projets de base de données plutôt que le simple "édite-le et c'est vérifié" que vous obtenez lorsque le contrôle de source est intégré dans votre IDE.
ChrisF
1
J'imagine que vous pouvez modifier votre base de données sans la valider pour le contrôle de version, mais vous ne pouvez pas vraiment faire la même chose avec du code ...
Jaco Pretorius
5
@ Jaco Non, mais vous pouvez exécuter / libérer du code sans le mettre dans le GDS. Sloppy Release Management est une gestion des versions peu soignée, quelle que soit la technologie utilisée.
Phil Lello
3
Si vous effectuez toutes les modifications avec des scripts, il vous suffit de les enregistrer dans le répertoire du contrôle de source et de procéder à leur archivage comme tout autre code. Il n’ya aucune raison pour laquelle il est difficile de travailler avec la base de données de contrôle de source.
HLGEM
8

Dans une entreprise dans laquelle je travaillais, la publication du code en production contenait beaucoup de formalités administratives et impliquait un DBA pour la publication du code était toujours un cauchemar. Nous avons toujours mis la logique dans la couche application pour éviter d'avoir à traiter avec des DBA avec lesquels il était difficile de travailler. C'est une raison totalement boiteuse mais dérivée de la nécessité.

Walter
la source
Il est déjà assez difficile d'élargir la taille de l'équipe sans inclure quelqu'un qui ne veut pas coopérer (vous ne savez pas pourquoi la personne en charge autorise ce choix) ou qui a besoin de sa propre «session de tutorat» pour être au courant des exigences.
JeffO
1
J'imagine que c'est parce qu'ils restent assis la plupart du temps sans rien faire, alors quand vous leur donnez enfin quelque chose à réviser, ils veulent vraiment attirer l'attention. Peut-être que c'est juste moi ...
Jaco Pretorius
5
@ Jeff O Pourquoi l'administrateur de la base de données n'a-t-il pas participé à la conception? Les administrateurs de bases de données ont tendance à en savoir beaucoup plus sur l'optimisation de la base de données que les autres développeurs et devraient être traités comme faisant partie de l'équipe.
Phil Lello
8
@Phil Lello: Parce que la plupart des développeurs de logiciels sont des clients arrogants qui pensent qu'ils peuvent tout apprendre eux-mêmes. C'est pourquoi tant de bases de données sont des piles de bric-à-brac.
JUSTE MON AVIS correct
2
On dirait que votre DBA a construit une clôture autour du champ de mines pour assurer votre sécurité. Soyez reconnaissant!
James Anderson
7

Mettre la logique d' application dans la base de données me semble une mauvaise idée. OTOH insère dans la base de données une logique qui fait spécifiquement partie du maintien de son état (par exemple, des triggers / sprocs pour mettre à jour des tables dé-normalisées) est une proposition très différente.


En guise d'alternative, cela peut se résumer ainsi: il existe de bons arguments pour mettre en place la logique nécessaire pour définir de manière abstraite le fonctionnement réel de la base de données par rapport à la manière dont vous souhaitez la consulter.

BCS
la source
Cette. Vous voulez que votre base de données soit résiliente. Donc, la logique liée à vos données devrait y résider.
Arkh
6

Après avoir lu les deux questions, je pense que nous avons peut-être tous manqué un point critique. La réponse correcte peut dépendre du type de logiciel que vous développez. Le groupe DBA travaille en grande partie sur des systèmes logiciels d'entreprise critiques et leurs réponses tendent à refléter ce qui est nécessaire dans ce monde. Il existe une énorme différence entre ce qui est nécessaire pour ces types d’applications et ce qui est nécessaire pour la prochaine application "Facebook". Ce n'est pas grave si vous perdez quelques poteaux muraux, mais si vous perdez quelques commandes ou autres transactions financières.

Les personnes qui travaillent dans le monde COTS (commercial sur étagère) ont tendance à être agnostiques vis-à-vis des bases de données pour des raisons commerciales et veulent que tout soit dans du code conforme, il est plus difficile de procéder à une ingénierie inverse et de remplacer leur produit par un produit fabriqué localement. Les applications d'entreprise développées et gérées en interne n'auront presque jamais besoin de changer de base de données, sauf pour la mise à niveau.

Les applications d'entreprise sont également celles qui ont tendance à avoir des entrées de nombreux endroits, la base de données étant l'unique caractéristique commune. Le système dans lequel je travaille a des centaines d'applications différentes qui y accèdent, ainsi que des centaines d'importations de données client, d'exportations de données vers des clients et des entrepôts de données, et utilise plusieurs systèmes de génération de rapports. Le code qui fonctionne bien lors de l'ajout d'un enregistrement est un échec lorsque je dois importer 20 000 000. Nous avons été obligés d'utiliser la couche d'application une fois parce que c'était là la logique et nous avons dû arrêter le processus 18 heures plus tard sans avoir terminé. La logique qui devrait s'appliquer à tous les enregistrements de données d'une table doit être dans la base de données lorsque vous ne pouvez pas avoir une couche de données que tout le monde utilise.

À l'inverse, lorsqu'une seule application consomme les données et que celles-ci ne sont pas vitales pour votre entreprise ou sont emphémères, les règles sont différentes et il est plus logique de mettre toute la logique dans l'application.

HLGEM
la source
4
C'est la meilleure réponse. Si la logique métier est dans l'application, s'il y a plusieurs applications utilisant une logique différente, la base de données peut se trouver dans un très mauvais état.
Sam
5

Assez long. voir le résumé en bas.

SGBDR

Un SGBDR est synonyme de système de gestion de base de données relationnelle. C'est un système pour gérer une base de données relationnelle. Les données sont stockées là. Les données. Cela ne dit pas la logique commerciale.

Processus d'affaires

Qu'est-ce que la logique commerciale signifie vraiment? Pour moi, c'est une description des processus métier en termes logiques.

Les processus sont les activités commerciales qui se produisent régulièrement, suffisamment pour qu’elles ne soient plus ad hoc. Celles-ci sont différentes pour chaque entreprise.

Permettez-moi de mettre le cap sur mes affaires et d'expliquer ce que signifie entreprise ici. Pour certains, cela peut être une surprise.

Affaires

Les affaires sont la somme des activités réalisées pour créer de la valeur, et plus spécifiquement de la valeur pouvant être échangée. Cela pourrait signifier faire des moissonneuses-batteuses, des sandwichs au thon ou des services bancaires. Dans la plupart des pays du monde, même dans les systèmes non capitalistes, les gens aiment obtenir le meilleur rapport qualité-prix, et il existe donc une concurrence entre différents fournisseurs de ces biens et services de valeur. La concurrence repose généralement sur le prix, la qualité et la disponibilité.

Petit détour: vous avez besoin de 40 millions de rivets en 2 jours, vous n’allez pas commander à un type sur Internet avec un compte paypal, peu importe combien son prix est inférieur à celui de votre fournisseur habituel.

Connaissance du processus

Comme vous pouvez l'imaginer, les processus impliqués dans la création de cette "valeur" résident principalement dans les chefs de secrétariat. Une partie de cette somme est mise sur papier et utilisée comme politique et procédures de l'entreprise. Une partie de celle-ci réside dans la tête des avocats d'entreprise. Une grande partie de cela réside dans la tête des responsables des divisions, des départements, des équipes et des opérateurs, des caisses enregistreuses, des fours et des camions. Un petit sous-ensemble de ces équipements réduit les exigences commerciales en matière de logiciels, et un sous-ensemble encore plus petit de ceux-ci est précis au moment de sa mise en œuvre dans les systèmes informatiques.

En fin de compte, la logique métier que vous voyez dans le code n'est pas celle qui exécute une entreprise, c'est celle qui exécute l'application pour l'entreprise. Les processus internes de l'entreprise sont gérés par des cerveaux et ils n'ont aucune difficulté à comprendre que le processus dans leur cerveau est plus précis que le processus de l'ordinateur. En passant, vous ne pourriez probablement pas diriger l’entreprise si vous ne respectiez que les politiques et procédures de la plupart des sociétés. Celles-ci sont très souvent inexactes, malgré les efforts herculéens.

En fin de compte, c'est la logique de l'application qui est codée dans le logiciel. Et les gens veulent inclure cela dans la base de données, car les fournisseurs de systèmes de gestion de base de données ont fait des déclarations grandioses.

Logique d'application

Je dis NON. Je dis que la logique de l'application reste à l'intérieur de l'application. Les données vont dans la base de données, de manière très normalisée, puis sont envoyées ETL'd au datawarehouse pour la génération de rapports, le forage, la synthèse, le pivotement et le cubage.

Les données

Je dis aussi que les données survivent à l'application, de sorte que l'effort de normalisation des données ne devrait pas être spécifique à une application, ni même à une entreprise, mais plutôt à une entreprise générale. Stockez-vous les codes d'état? Vous devez utiliser INCITS 38: 2009 (http://www.census.gov/geo/www/ansi/statetables.html) car ce logiciel est portable pour toutes les entreprises. Cela facilite également la manipulation des données par plusieurs applications.

NoSQL?

Si vous traitez la base de données comme faisant partie du code de l'application, de la disposition des tables aux déclencheurs, procédures stockées et formats de données, vous utilisez essentiellement la base de données d'entreprise comme une BerkleyDB glorifiée, qui est une structure de fichiers plats glorifiée, ce qui est vraiment juste des listes persistantes. C'est essentiellement ce que NoSQL est en train de faire: revenir aux racines, mais le faire de manière multi-processus, persistante et tolérante aux pannes.

Code actuel

Non, vous devez traiter la base de données comme un référentiel commun de données pour plusieurs applications, actuelles et futures. Nous arrivons maintenant au coeur de mon argumentation. Les processus commerciaux changent avec les aléas du marché, de la politique et de la mode. Très souvent, ils changent plus rapidement que ce que les codeurs peuvent gérer avec des langages informatiques (Java, C #, C ++, etc.) et finissent par être écrits en VBA dans des feuilles de calcul Excel du département comptabilité ou marketing. (Et seulement si cela ne peut pas être exprimé en vlookups de fantaisie ...)

Dégradation de la base de données

Les données ne changent pas beaucoup si elles sont bien organisées. La logique métier change très vite. En plaçant la logique métier dans la base de données, vous la rendez moins précieuse, car elle deviendra rapidement obsolète et inexacte.

Sommaire

Les données doivent survivre à l'application, car les processus métier y sont actifs et changent beaucoup plus souvent. Inclure la logique métier dans la base de données nuit à sa longévité et à sa valeur globale.

Caveat

J'ai fait ma part de travail et j'ai lu les réponses sur dba.se, mais en toute honnêteté, il est question de problèmes d'intégrité des données et de performances. Je suis tout à fait d’accord pour dire que les personnes qui manipulent des données d’entreprise doivent savoir ce qu’elles font, qu’il s’agisse de dba ou programmeur ou d’un analyste senior SAS disposant d’un accès en lecture / écriture.

J'ai également noté qu'ils recommandent aux codeurs de connaître SQL. Je suis d'accord. C'est un langage de programmation informatique, donc je ne vois pas pourquoi les programmeurs ne voudraient pas le savoir.

Plus tard, après y avoir pensé

Je pense que le moyen terme est de créer une API et de la laisser gérer le flux de données. Si vous ne pouvez pas autoriser les applications à se connecter directement aux tables, vous pouvez au moins configurer le mécanisme d'accès dans les langues modernes.

Christopher Mahan
la source
5
Je ne suis vraiment pas le point de dégradation de la base de données; en plaçant la logique dans la base de données, il vous suffit de modifier les règles à un seul endroit (la base de données), pas beaucoup d'applications écrites dans plusieurs langues. Cependant +1 pour une réponse bien pensée.
Phil Lello
3
Je dois souligner que de nombreux développeurs qui pensent que tout le processus devrait aller dans l'application incluent l’intégrité des données. C'est l'une des raisons pour lesquelles tant de bases de données ont une intégrité de données médiocre. Et la performance est l’un des trois facteurs les plus critiques pour une base de données (avec l’intégrité et la sécurité des données), aussi nous sommes bien sûr préoccupés par cela!
HLGEM
1
Les données sont seulement aussi bonnes que l'application. Des ordures à la poubelle et tout ça. Si vous avez, hum, des personnes imprécises qui écrivent les applications, vous ne pouvez pratiquement rien faire en tant qu'administrateur de base de données pour rectifier les ordures.
Christopher Mahan
1
@ChristopherMahan, vous pouvez faire beaucoup de choses en matière de conception de base de données pour éviter les données incorrectes.
HLGEM
4

Au risque de paraître dramatique, je suis vraiment horrifié par l’idée d’une logique d’application dans la base de données. Beaucoup de réponses ici ont mis l’accent sur les avantages du développement de logiciels. Par souci de brièveté, je vais me concentrer sur les avantages procurés par le partage des responsabilités.

Les bases de données constituent un moyen efficace de stocker et d’accéder aux informations, tout en minimisant les données redondantes et en générant des relations logiques entre les données. Bien que la logique de base de données puisse être capable de mettre en œuvre une logique métier au niveau de la production, mon opinion personnelle est que la base de données devrait être aussi agnostique que possible pour les applications afin de garantir que les données puissent être efficacement exploitées par plusieurs applications tout en exploitant les atouts respectifs de la base de données. moteur par rapport aux points forts du langage d'implémentation de l'application.

Un utilisateur de l’échange de pile DBA a déclaré ceci ...

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.

... suivi de sa conviction que cela indique une violation du principe DRY.

Plutôt que d'être une répétition de la logique métier, je pense qu'il s'agit plus probablement d'un exemple parfait de la flexibilité fournie par une division distincte des responsabilités entre la couche métier et la couche données.

Leur base de données OLTB fournit des données fiables et efficaces à plus de 25 applications depuis des décennies! C'est incroyable! (Marche à suivre!)

Je ne peux que supposer que les données sont suffisamment agnostiques pour fournir du contenu à un certain nombre d'applications distinctes. Ce qui serait en grande partie impossible si ces développeurs tentaient de pirater quelque chose en utilisant la logique de base de données.

Comme d'autres réponses l'ont indiqué, il existe de nombreuses autres raisons de ne pas implémenter un programme dans la base de données. Je suis sûr que cela fonctionnerait, mais le résultat le plus probable serait des décennies de regret, plutôt que des décennies de stabilité.

M. Smith
la source
Bien dit. Mon gros problème avec les procédures stockées, l’intégrité référentielle, etc., est la gestion des erreurs. "Trop souvent, l'utilisateur final se voit présenter" la procédure d'objet d'erreur de mulching YYYY XXXXXX - sqlcode -666 ", ce qui entraîne une perte de temps pour les appels au support. Lorsqu'un simple "client n'a pas d'identifiant de taxe", l'utilisateur pouvait résoudre le problème et poursuivre son travail.
James Anderson
3

Les applications agnostiques aux bases de données nécessitent toute la logique des bases de données. Il est très difficile de créer et de maintenir du code pour de nombreux fournisseurs de bases de données.

Maniero
la source
3
Il est très difficile de construire des entrepôts de données indépendants des applications avec une logique basée sur les applications
Phil Lello
3

Un bon développement trouvera un bon équilibre entre le besoin d'intégrité et de rapidité de la base de données en intégrant une partie de la logique dans la base de données et la majeure partie de celle-ci dans l'application.

La même requête sera-t-elle utilisée maintes et maintes fois dans de nombreuses applications, elle appartiendra peut-être à une procédure stockée.

S'assurer que les champs de gestion interne sont définis lorsqu'une ligne est insérée et mise à jour est une responsabilité du DBA. Un déclencheur sera utilisé.

D'autre part, si j'ai une logique métier, celle-ci doit figurer dans l'application. Lorsque cela est possible, il doit appeler des procédures stockées qui renverront le jeu d’enregistrements filtré souhaité avec le nombre exact de champs nécessaires. Pas plus, pas moins.

C'est une question de communication entre les équipes et de reconnaissance des avantages et des inconvénients de chaque possibilité.

Mon opinion est la suivante: ne placez pas la logique d'application trop profondément dans DB.

Nicolas de Fontenay
la source
2

Certains systèmes de trading fournissent un moyen d'étendre les fonctionnalités existantes avec des scripts, placés dans la base de données. Mon expérience avec cela est plutôt négative, du moins dans un contexte multi-utilisateur.

Vous mettriez la logique dans une base de données, car vous voudriez pouvoir la modifier facilement.

  • Comment feriez-vous le contrôle de version?
    • Quel est l'historique du code? Quels ont été les changements? Par qui?
    • Comment gérez-vous les changements sur les mêmes fragments de code?
  • Comment identifier et garantir un état de code cohérent?

Vous pouvez suivre cela dans un VCS supplémentaire basé sur des fichiers, mais quels sont les avantages de la base de données?

LennyProgrammers
la source
Tout le code de base de données doit être dans le contrôle de source dans tous les cas C'est un code comme un autre.
HLGEM
1

La plupart des applications doivent avoir un moyen de fournir une intégration. Idéalement, vous devriez avoir une API complète, un service Web ou au moins rendre disponibles certains objets de base de données contenant une logique métier. Tout le monde n’est pas dans une position temps / ressources pour créer une API, vous devez donc faire des compromis.

JeffO
la source