Une base de données pour plusieurs applications?
Quelqu'un a-t-il travaillé dans un environnement où plusieurs applications internes sont toutes regroupées sous une seule base de données, chaque application disposant de son propre schéma dans cette base de données unique? Je ne parle pas seulement de quelques petites applications connexes dans une seule base de données, mais comme des applications complètes sur des unités autonomes mises dans une seule base de données avec d'autres applications autonomes.
J'ai affaire à une architecture comme celle-ci qui a été mise en place bien avant moi et j'essaie de faire valoir qu'une nouvelle application autonome devrait être placée dans sa propre base de données distincte, mais on me dit essentiellement que cela "met tout en un L'architecture de base de données est plus logique qu'une base de données distincte et je ne sais même pas quoi dire. J'ai l'impression que je ne trouve pas beaucoup d'informations à ce sujet sur Internet parce que personne d'autre ne met plusieurs applications dans une seule base de données comme celle-ci, mais peut-être que je me trompe complètement?
Je travaille avec Microsoft SQL Server et les applications Web .NET.
Oui, j'ai travaillé dans un environnement similaire.
La différence entre un schéma et une base de données n'est pas énorme du point de vue de l'application. Après tout, toutes les bases de données d'un serveur s'exécutent sur le même serveur. Je ne le ferais pas transpirer.
L'essentiel est que vous mainteniez une séparation entre les tables et que vous n'ayez pas une référence d'ensemble ou que vous ayez des requêtes qui s'étendent sur des domaines.
Je laisserais la configuration de la base de données aux DBA et m'assurerais simplement que mon SQL était bon.
En bref
J'ai travaillé dans les deux types d'environnements. J'étais un promoteur inconditionnel de l'approche partagée-db. Il m'a fallu un certain temps pour voir son limitations et pour reconsidérer: n'envisagez-le que pour des applications étroitement liées fonctionnant dans le même contexte délimité .
En général, la base de données partagée fonctionne très bien. Comme les programmes COBOL avant eux. Et comme eux, ils nous font toujours voir les données comme quelque chose de passif qui attend d'être traité par un logiciel qui sait comment les traiter (et qui le fera correctement). Les bases de données uniques ont l'avantage de permettre aux applications de partager des données d'entreprise. Exactement comme les données globales sont partagées par différents modules.
Mais l'ingénierie logicielle moderne nous a appris à encapsuler des modules, à éviter les données globales et à suivre la méthode OO: les données n'ont de sens qu'avec le code qui peut les gérer de manière fiable. Pourquoi continuons-nous à ignorer ces principes au niveau de la base de données?
En long
Le graal de la base de données d'entreprise unique
Le single-db fonctionne très bien, car dans une entreprise, toutes les activités sont en quelque sorte liées. C'est le principe de nombreux ERP de premier plan. Le fait d'avoir tout dans une seule base de données vous permet d'intégrer en temps réel différentes applications très facilement.
Avantages:
- Coûts d'exploitation réduits
- Opportunités de réingénierie des processus: toutes les données sont là; vous êtes donc libre de redistribuer les fonctionnalités entre les applications.
- Opportunité de rationaliser la conception de la base de données: fin des années 80 début des années 90 j'ai assisté à quelques projets de centralisation, avec une réduction impressionnante du nombre de logiciels d'application (en particulier ETL/programmes d'interface)
- Synergies: différentes équipes partagent les mêmes compétences et peuvent partager des idées en communiquant sur leur schéma DB.
Risques et inconvénients:
- Le succès dépendra de la capacité de conception du schéma de base de données dans une perspective globale, à travers les domaines. Si tout le monde continue de construire un château de sable dans son propre espace de noms, vous aurez les inconvénients de la base de données mondiale sans la plupart de ses avantages.
- couplage fort des composants: vous ne pouvez plus réutiliser une application dans un contexte différent (un autre site, une autre entreprise), car les données sont entrelacées avec beaucoup d'autres applications.
- Dépendances inconnues: Étant donné que tout est lié dans une base de données et qu'il est facile d'accéder à une table dans un autre schéma/espace de noms, les dépendances ne sont pas claires. Cela a bien sûr un impact sur l'organisation des développements: êtes-vous sûr que certaines tables de base de données que vous avez testées n'ont pas été modifiées par un développeur d'une autre application? Comment organiser l'évolution de la base de données ?
- Un programme mal comporté peut créer des incohérences sur la base de données
- L'évolutivité est finalement limitée par l'évolutivité de votre moteur de base de données.
- Ralentissement de l'innovation, en partie à cause de la peur? En raison des dépendances inconnues, la plupart du temps, les ingénieurs SW préfèrent ne pas toucher à une base de données de production fonctionnelle.
- Le vendeur est bloqué?
Mais ne sommes-nous pas dans un monde différent maintenant?
De nos jours, la tendance est d'éviter le monolithe et de concevoir des architectures évolutives et évolutives flexibles:
- Dans notre monde Internet, l'application peut communiquer via des services Web et ne nécessite plus de base de données commune pour échanger en temps réel.
- Microservice architecture même sujette à éviter une base de données partagée : chaque (micro) -service devrait avoir sa propre base de données privée , donc pour augmenter le découplage et accélérer le déploiement de nouveaux développements.
- Les opérations cloud permettent de reconsidérer les coûts d'exploitation sous un angle totalement différent. Vous ne vous souciez plus du nombre de serveurs dbs dont vous avez besoin pour patcher, mettre à niveau ou sauvegarder: c'est inclus dans le prix.
- NoSQL a fait son chemin vers le courant dominant: de nombreuses applications peuvent parfaitement fonctionner avec un SGBDR. Mais il existe des problèmes spécialisés qui sont mieux traités avec différentes technologies: une base de données graphique, une base de données orientée document, ou le besoin de tri géolocalisé peut favoriser un moteur de base de données spécialisé. La stratégie à une base de données serait un bloqueur.
- Certaines applications n'ont pas besoin d'une base de données. Par exemple, les flux d'événements traitent en temps réel de grandes quantités de données entre les applications, sans nécessiter le partage des données sur une base de données (l'équivalent de la base de données nécessiterait des requêtes répétitives inefficaces pour détecter de nouvelles données).
Conclusion
La clé d'une bonne architecture n'est plus de définir les bonnes tables dans une seule base de données, mais de définir les bonnes API, en laissant les services faire le lien entre les différentes applications.
Cela étant dit, ne soyons pas dogmatiques. Pour les applications étroitement liées fonctionnant dans le même contexte délimité, une base de données partagée est toujours un alternative valide =.
J'ai également été dans des situations où différentes applications se trouvaient dans la même base de données. Je comprends votre frustration, mais parfois, les "meilleures pratiques" font l'objet de "bonnes affaires".
Comme vous l'avez souligné, si les applications étaient liées, il serait évidemment plus logique de les avoir sur la même base de données. S'il y a une raison commerciale (comme les autres réponses et commentaires soulignés), vous pouvez accepter cette raison ou essayer de faire une meilleure raison commerciale pour les séparer. Deux, je peux penser, seraient les problèmes de sécurité et l'évolutivité possibles. De nos jours, de nombreuses applications sont virutalisées et conteneurisées. Il est trivial d'ajouter une base de données dans un conteneur Docker servi avec des applications dockées latérales (ou quelle que soit l'application de conteneur que vous utilisez). Bien sûr, cette ligne suppose que les frais de licence ou de personnel ne l'emportent pas sur les avantages de pouvoir ajouter un autre conteneur au besoin.
Donc, pour résumer, leur architecture n'est pas inconnue, c'est fait. Si vous souhaitez suggérer une direction différente, comprenez pourquoi ils ont pris leur décision (technique ou commerciale) et essayez de présenter un argument qui affecte ce domaine.