Dois-je utiliser une base de données par application ou partager une seule base de données entre plusieurs applications [fermé]

J'ai plusieurs applications dont certaines utilisent des données provenant des mêmes sources. Est-ce la meilleure pratique (ou quels sont les avantages / inconvénients) de:

• laisser les données dans des bases de données partagées par plusieurs applications

  1. économise de l'espace car une seule base de données est nécessaire
  2. complique l'indexation car différentes applications ont des besoins d'interrogation différents

• importer des données quotidiennement dans des bases de données par application

  1. utilise plus d'espace car des données dupliquées existent dans les bases de données par application
  2. indexation plus facile car chaque application peut se concentrer sur ses besoins individuels

J'ai peut-être omis d'autres avantages / inconvénients, veuillez en indiquer le cas échéant, et comment cela se fait-il sur votre lieu de travail?

L'espace est bon marché de nos jours, donc je vous conseille d'utiliser une base de données par application.

Le partage d'une base de données pour plusieurs applications présente de sérieux inconvénients :

• Plus les applications utilisent la même base de données, plus il est probable que vous rencontriez des goulots d'étranglement de performances et que vous ne puissiez pas facilement mettre à l'échelle la charge comme vous le souhaitez . Les bases de données SQL ne sont pas vraiment évolutives. Vous pouvez acheter des machines plus grandes, mais elles ne s'adaptent pas bien en grappes!

• Les coûts de maintenance et de développement peuvent augmenter : le développement est plus difficile si une application doit utiliser des structures de base de données qui ne sont pas adaptées à la tâche à accomplir mais doivent être utilisées car elles sont déjà présentes. Il est également probable que les ajustements d'une application auront des effets secondaires sur d'autres applications ("pourquoi y a-t-il un déclencheur si inutile ??!" / "Nous n'avons plus besoin de ces données!"). C'est déjà difficile avec une base de données pour une seule application, lorsque les développeurs ne connaissent pas / ne peuvent pas connaître tous les cas d'utilisation.

• L'administration devient plus difficile: quel objet appartient à quelle application? Le chaos monte. Où dois-je rechercher mes données? Quel utilisateur est autorisé à interagir avec quels objets? Que puis-je accorder à qui?

• Mise à niveau: vous aurez besoin d'une version qui est le plus petit dénominateur commun pour toutes les applications qui l'utilisent. Cela signifie que certaines applications ne pourront pas utiliser de fonctionnalités puissantes. Vous devrez vous en tenir aux anciennes versions. Cela augmente également un peu les coûts de développement.

• Concurrence: pouvez-vous vraiment être sûr qu'il n'y a pas de dépendances chronologiques entre les processus? Que se passe-t-il si une application modifie des données obsolètes ou auraient dû être modifiées par une autre application en premier? Qu'en est-il des différentes applications travaillant simultanément sur les mêmes tables?

Par rapport à cela, les processus d'importation de données / ETL sont presque toujours assez directs et simples. Chargez les données aussi souvent que nécessaire, l'espace est bon marché. Vous pouvez prendre en compte l'évolutivité de chaque application indépendamment, ajuster et modifier les structures selon vos besoins et il n'y aura pas de problèmes de concurrence. Les effets secondaires peuvent également être tracés beaucoup plus facilement.

Edit: Je voudrais cependant souligner que, comme @Saeed l'a mentionné, si vous pouvez encapsuler des manipulations de données dans un service qui est couramment disponible, il est plus facile de partager une base de données avec plusieurs applications. Tant que vous n'avez pas besoin d'un accès brut, c'est une très bonne approche.

J'ai eu une situation similaire une fois. Mon problème était de créer 3 applications, une pour la gestion des stocks, une pour la gestion des achats et une pour la gestion des utilisateurs, c'est-à-dire des employés. Ma recommandation est de ne pas casser physiquement les bases de données par application, ni de les rejoindre physiquement par application. Au contraire, la séparation logique à mon humble avis fonctionne mieux.

Par exemple, les 3 applications devaient fonctionner avec les informations sur les employés. Les systèmes d'inventaire et d'approvisionnement utilisaient les mêmes informations sur les marchandises et les articles en stock.

J'ai créé une base de données partagée, dans laquelle je stockais les informations des utilisateurs et des biens. Ensuite, j'ai créé une couche de service dessus et j'ai utilisé ces services dans d'autres applications. Pour afficher une liste de tous les employés qui sont maintenant dans l'entreprise par exemple, je n'avais qu'à appeler une méthode du service comme GetOnWorkEmployees().

J'ai également créé une interface utilisateur commune pour interagir avec les utilisateurs et les marchandises, qui était une application Web distincte en elle-même.

Donc, en ajoutant à ce que @Falcon a souligné, je pense que vous pouvez bénéficier de la centralisation des fonctionnalités communes aux applications dans une seule base de données.

Si ces applications sont censées fonctionner à partir des mêmes données - par exemple, la même liste de produits et de clients -, conservez la base de données ensemble. Vous ne gagnez rien en séparant les bases de données. C'est purement un problème «humain» - pour le serveur ses seuls octets sur un disque. Il se fiche de ses 1 ou 100 bases de données. Mais si vous le divisez, vous devez alors gérer la synchronisation des données. Les problèmes d'indexation que vous évoquez ne sont pas un vrai problème - vous passeriez le même temps de processeur à maintenir les index si les bases de données étaient divisées.

Si les performances commencent à devenir un problème, répliquez la base de données sur plusieurs serveurs pour équilibrer les choses.

Cela peut ou non valoir la peine d'être compromis dans votre situation, mais le maintien de l'intégrité des données est plus facile avec une seule base de données. Dans MS SQL Server au moins, vous ne pouvez pas extraire de clé d'une base de données vers une autre base de données. Vous pouvez simuler le comportement d'une clé étrangère avec des déclencheurs, mais ce n'est pas particulièrement élégant.

De plus, la création de copies locales des données peut être dangereuse lorsque des écritures entrent en jeu. Si AppA et AppB ont tous deux une copie de certaines données partagées et que AppA la met à jour, AppB conservera toujours les anciennes données. Ou, vous devrez configurer des déclencheurs pour garder les données synchronisées.

Une fois, j'avais plusieurs sites Web qui sont devenus populaires au fil du temps. Ils ont utilisé des bases de données distinctes, principalement parce que le fournisseur d'hébergement n'autorisait que 1 Go d'espace de stockage chacun. Mais! Dès que j'ai publié un service qui comprenait tous ces sites Web, j'ai commencé à devoir effectuer des transactions entre ces sites Web, et le moyen le plus pratique de le faire est de tout déplacer définitivement dans une grande base de données.

J'ai donc optimisé la structure de la base de données et pressé les parties pertinentes de cette base de données centrale, mais j'ai laissé tout le reste de côté.

Mon opinion est en quelque sorte liée aux paradigmes de la POO. Des données similaires doivent être stockées ensemble, donc si vous créez différentes applications, vous devez utiliser différentes bases de données pour elles.

Dans le cas ci-dessus, l'utilisation de la base de données commune ne pouvait pas être évitée, mais rappelez-vous que j'ai également gardé certaines tables séparées dans une base de données distincte, qui ne font pas partie des requêtes courantes.

De plus, si vous les gardez séparés, ils seront plus faciles à sauvegarder, il y aura moins de risques de perte de données. Si quelque chose ne va pas et que les applications interfèrent les unes avec les autres, la base de données est gâchée et vous ne voulez essentiellement pas exposer votre application à ce danger.

Dans l'ensemble, vous pouvez gérer une base de données commune pour les requêtes courantes, mais également en conserver une pour chacune de vos applications.

Pouvez-vous nous en dire plus sur l'architecture de votre application?

Si votre base de données fonctionne comme un référentiel de données sans logique d'application comme les déclencheurs ou le code de package métier, il serait préférable d'avoir une base de données unique et d'encapsuler les fonctionnalités de niveau métier aux services qui utilisent la base de données pour toutes leurs actions. Si vous avez des déclencheurs ou du code dans le schéma de base de données, vous aurez de gros problèmes en utilisant une seule base de données qui peut être gênante dans de nombreux cas.