Logique métier: base de données vs code
Je suis un étudiant en ingénierie des systèmes, et tous mes professeurs et amis (qui travaillent réellement dans le domaine) disent qu'il est préférable d'avoir autant de logique que possible implémentée dans la base de données (requêtes, vues, déclencheurs, T-SQL , etc.). Je pense qu'il vaut mieux l'avoir dans le code.
Leurs raisons sont:
S'ils doivent changer de langue, presque toute la logique sera dans la base de données; par conséquent, le temps de mise en œuvre sera minime.
Les changements de langue sont plus courants que dans la base de données.
Mes raisons sont:
Il est évident (dans l'environnement actuel de mon pays au moins) qu'ils ne changent pas la langue des projets "facilement". (J'ai vu des programmes qui sont toujours dans FoxPro , car si cela fonctionne, il n'est pas nécessaire de le changer).
Les langages de programmation concernent la fonctionnalité, tandis que les bases de données concernent les données. Vous pouvez avoir une fonctionnalité de programmation dans les bases de données, mais je pense qu'elle devrait être limitée aux composants qui affectent les données.
Il est plus facile de mettre en œuvre de nouvelles exigences (par exemple: si le client veut une API).
Normalement, lorsqu'ils utilisent la logique dans la base de données, le reste de la logique implémentée dans le code ressemble plus à du spaghetti (fonctions aléatoires, par exemple).
Généralement, il est plus courant d'avoir plus de programmeurs que d'administrateurs de base de données (DBA).
Quelle implémentation est la meilleure?
Voir Quelle logique métier la base de données doit-elle implémenter? pour la discussion précédente.
En général, tout le monde veut que les choses soient faites dans la couche qu'il contrôle. Parce qu'alors ils le contrôlent.
Chaque fournisseur de base de données souhaite que les gens mettent autant de logique que possible dans la base de données. Parce que cela vous enferme dans la base de données. Le raisonnement est que si plusieurs applications utilisent la même base de données, elles réutilisent le code.
Cependant, les programmeurs sont catégoriquement en désaccord. Les bases de données offrent de mauvaises options de programmation. Le déploiement de code dans des bases de données est difficile. Les bases de données manquent d'outils de base pour le contrôle des révisions, l'édition interactive, le déploiement et les tests unitaires. Les procédures stockées ont tendance à impliquer une action horrible pour déboguer à distance. Il est devenu moins courant que plusieurs applications atteignent la même base de données. Et si jamais vous devez faire évoluer quelque chose, le goulot d'étranglement le plus difficile à résoudre est votre base de données.
Mon parti pris est clair. Je suis programmeur.
Mais je programme depuis près de 20 ans, principalement en tant que programmeur principal responsable des données. J'ai vu l'argument à plusieurs reprises pour déplacer la logique dans la base de données. J'ai vu des systèmes qui l'ont fait et des systèmes qui l'ont évité. J'ai dû migrer des bases de données, migrer des bases de code, etc., etc., etc.
Les pires dégâts ont toujours été lorsque la logique métier était dans la base de données. Ils ont toujours été les plus difficiles à corriger. Et je peux dire que bien que j'ai rencontré à plusieurs reprises l'affirmation selon laquelle "nous avons déplacé la logique dans la base de données pour des performances", les performances sont presque toujours meilleures avec un modèle de données normalisé propre, de bons index, une couche de mise en cache devant la base de données, et des algorithmes sensés implémentés dans un langage de programmation moderne.
Je suis très fermement d'avis que lorsque cela est possible, la logique métier doit être conservée dans la couche logicielle et non dans la couche base de données. Notez que lorsque cela est possible est toujours loin de toujours .
Il existe des arguments solides pour les deux façons, et comme toujours, utilisez un bon jugement d'ingénierie pour décider pour chaque projet combien de poids doit être appliqué à chaque point avant de décider quel est le choix le plus approprié.
( comme d'autres personnes font des suggestions dans les commentaires, elles peuvent être ajoutées à la liste )
Arguments pour la base de données gérant la logique métier:
- La logique métier a besoin de données pour fonctionner. Obtenir le traitement logique au plus près des données donne de meilleures performances
- Un seul endroit pour appliquer les mises à jour
Arguments pour les couches logicielles gérant la logique métier:
- Un logiciel bien écrit est généralement beaucoup plus facile à comprendre, à déboguer et à maintenir que les procédures stockées SQL.
- Les serveurs d'applications peuvent évoluer et évoluer si l'application Internet devient populaire.
En tant que développeur professionnel chevronné, nécessitant une solution rapide pour améliorer la latence des applications, le choix peut être entre le déplacement d'une logique métier à exécution lente dans une procédure stockée sur la base de données et/o pour implémenter la mise en cache des processus lents.
Il existe cependant un sérieux problème avec la logique métier basée sur les bases de données. Si votre application doit évoluer massivement, préférez toujours les systèmes/processus qui peuvent évoluer (j'entends par là, vous pouvez ajouter plus de serveurs dans le pool de traitement). Les bases de données SQL peuvent uniquement évoluer (vous devez trouver un serveur plus puissant pour remplacer votre serveur existant.) Si votre application possède beaucoup de logique métier de base de données, vous rencontrerez ce problème plus tôt.
Deux points très importants manquent dans vos arguments pro-base de données:
- performances : le code de la base de données est exécuté avec un accès direct aux données, évitant ainsi les transferts inutiles (que ce soit lors de la récupération d'API et de schémas de mappage sur la même machine, ou à travers le réseau pour la communication client/serveur)
- cohérence : étant donné que plusieurs applications peuvent accéder/mettre à jour la même base de données, encapsulant la cohérence et les règles métier de manière centralisée, garantit qu'elles seront appliquées de manière fiable.
Mais certains points très importants manquent également sur vos arguments de contre-base de données:
évolutivité : plus vous mettez sur la base de données, plus ce composant deviendra un goulot d'étranglement. Bien sûr, vous pouvez prendre de plus gros serveurs et ajouter des processeurs, mais tôt ou tard, vous atteindrez les limites physiques.
verrouillage du fournisseur : SQL est très standardisé, mais les langages des déclencheurs et des procédures sont plutôt diversifiés et souvent propriétaires: T-SQL pour Microsoft, PL/SQL pour Oracle, n'importe quelle langue pour DB2. Le développement de la base de données vous enferme pour un fournisseur et ne vous permet pas de profiter d'une concurrence accrue ou de migrer vers de nouveaux environnements d'exploitation.
architecture héritée : surcentralisation des données et traitement sur d'énormes serveurs ... Cela ne nous ramène-t-il pas à l'ère des mainframes? Cela semble obsolète de nos jours, lorsque de nouvelles tendances architecturales majeures émergent visant une évolutivité maximale: flexible NoSQL bases de données de différents types idéalement adaptées au développement orienté objet, microservices = avec chaque microservice ayant sa propre base de données, et une architecture bigdata telle que architectures lambda où tous les pipelines de traitement sont en dehors de la base de données.
arguments obsolètes : le temps du code cobol redondant sujet aux erreurs copié entre les applications est révolu. Ce qui ne pouvait être encapsulé de manière fiable qu'hier dans un SGBDR, peut très bien être encapsulé dans des architectures logicielles modernes, en utilisant des composants orientés objet maintenables et réutilisables, des bibliothèques et des systèmes de contrôle de version.
Résumer:
- oui, il existe des arguments valables pour mettre le maximum de logique du côté de la base de données. Mais ces arguments ne répondent cependant plus aux nouveaux besoins et contraintes de l'échelle Internet, au changement technologique et à l'émergence des bigdata.
- non, je ne pense pas qu'il existe une meilleure approche universelle. L'approche la plus appropriée doit être choisie par un architecte logiciel, au cas par cas, en fonction des exigences et des besoins concrets.
Outre tous les faits qui ont déjà été signalés, rappelez-vous également que le fait d'avoir une logique métier dans votre code plutôt que la base de données s'avère finalement moins cher.
Lorsque vous recherchez un développeur pour une application écrite en PHP et en utilisant MySQL comme base de données, si votre logique métier est stockée dans le base de données, un simple PHP programmeur ne suffit pas, et vous devrez trouver quelqu'un qui sait également écrire, déboguer et optimiser les procédures stockées. Soudain, vous avez besoin d'un gars qui ne sait pas seulement une chose , PHP, mais deux, PHP et programmation MySQL.
Et ne pensez même pas à passer à un moteur plus performant comme PostgreSQL , alors vous devez également embaucher un gars pour transformer toutes les procédures stockées en PL/SQL .
Lorsque vous avez une logique métier dans le code, il ne s'agit que d'écrire une nouvelle couche d'abstraction pour PostgreSQL et d'échanger les dépendances dans votre application, boom, votre application connaît soudainement PostgreSQL.
Les réponses précédentes donnent de bonnes raisons pour lesquelles il est plus facile/préférable de mettre la logique dans le code d'application vs dans une base de données. Une exception que je voudrais souligner est lors de l'utilisation d'une base de données Big Data/pile technologique. Dans ce cas, de nombreux inconvénients disparaissent:
- Vous pouvez écrire des tests unitaires car c'est le code que vous avez écrit qui se trouve dans la base de données.
- Vous pouvez déboguer, mais à travers des tests unitaires.
- Vous avez le contrôle de version, puisque c'est du code.
Et les avantages d'avoir la logique dans la base de données deviennent beaucoup plus importants:
- Selon la quantité de données en cours de traitement, il peut être déraisonnable d'envoyer des données à votre code d'application.
- Mise à l'échelle - votre code évolue de la même manière que les bases de données - dans de nombreux cas, les performances et le stockage sont linéaires en nombre de nœuds (machines).
Grande question - c'est quelque chose que je préconise très régulièrement au bureau.
À mon avis, la majeure partie de la logique devrait être en code. Il est toujours très tentant d'utiliser une variété de langues car elles ont chacune leurs points forts, mais à moins d'avoir une configuration de développement parfaite (ce qui est très rare), il est préférable de s'en tenir à une seule langue.
Les gens ont mentionné les tests unitaires/le contrôle de révision versionning, mais une chose très importante est le déploiement. Devoir synchroniser les modifications du code de la base de données avec les modifications du code peut être dangereux.
Si vous êtes dans une entreprise de développement de logiciels à grande échelle, vous pouvez avoir suffisamment de personnes spécialisées qui connaissent les deux côtés (programmation de base de données vs codage), mais sinon, il est difficile de trouver des personnes qui peuvent jongler entre les 2 mondes (et surtout, qui faire les bons compromis quand il s'agit de décider quelle partie de la logique doit être dans quelle langue).
Personnellement, je trouve les langages de programmation SQL très primitifs et leurs outils de développement encore pire. Je privilégierais donc les langages de programmation modernes. Un bon ORM peut sauver la plupart des développeurs de ne rien savoir de la base de données et mérite d'être investi. Les gens ont mentionné l'efficacité de faire les choses côté serveur, et cela ne devrait pas être abandonné. Il existe des modèles de programmation très agréables qui permettent d'exprimer des opérations côté serveur en utilisant ce qui semble être une API côté client (par exemple IQueryable en C #).
Dans la pratique, j'utilise toujours les vues étranges ou les procédures stockées, mais elles sont généralement principalement purement pour l'agrégation et n'ont aucune logique "métier". Ceci est très utile car ils peuvent être utilisés comme sources pour les pivots Excel par exemple.