Base de données par application VS Une grande database pour toutes les applications

Cela dépend et vos options sont un peu différentes selon la database et les frameworks que vous utilisez. Je recommand d'utiliser une sorte de ORM et de cette façon vous n'avez pas besoin de déranger autant. Quoi qu'il en soit, vous pouvez probablement placer chaque application dans son propre schéma dans la database, puis referencer les tables partagées par schemaname.tablename ou créer des vues dans chaque schéma d'application qui est juste un SELECT * FROM schemaname.tablename , puis le code contre cette vue.

Aucune des deux ne semble idéale

Je pense que vous devriez envisager de ne pas faire de references dans la couche de database pour les relations inter-applications, et les faire dans la couche application. Cela vous permettrait de le split en une database par application.

Je travaille sur une application avec plus de 100 tables. Je les ai dans une database, et sont séparés par des préfixes – chaque table a un préfixe pour le module auquel elle appartient. Ensuite, j'ai construit une couche au-dessus des fonctions de database pour utiliser ces groupes personnalisés. Je construis aussi l'administrateur de données, qui tire parti de ces groupes de tables et rend datatables d'édition très faciles.

Il n'y a pas de règles ssortingctes pour choisir l'une par rapport à l'autre.

Plusieurs bases de données fournissent la modularité. En ce qui concerne la synchronisation entre plusieurs bases de données, on peut utiliser le concept des servers liés et des vues de ceux-ci et get les avantages de la database embeddede (access unifié).

De plus, garder plusieurs bases de données peut aider à mieux gérer la security, datatables, la sauvegarde et la restauration, la réplication, la mise à l'échelle, etc.

Mes 2cents.

Cela ne ressemble en rien à "beaucoup d'applications", mais plutôt à "un système d'application avec des exécutables différents". Naturellement, ils peuvent partager une database. Faites une utilisation intelligente de Schemata pour isoler les différentes zones fonctionnelles dans une database.

Une database pour toutes les applications à mon avis. Les données seraient stockées une fois sans répétition.

Avec l'autre approche, vous finiriez par vous répliquer et, à mon avis, lorsque vous commencerez à le reproduire, votre mal de tête s'accélérera et datatables ne seront plus synchronisées.

L'approche la plus appropriée du sharepoint vue de l'évolutivité et de la maintenance serait de rendre le sous-set de tables "partagées / communes" autosuffisant et de le mettre dans la database "communes", toutes les autres ayant 1 db par application. déterminé) et maintenir cette structure toujours

Cela facilitera la planification et l'exécution des procédures de mise en service / désaffectation / relocalization / maintenance de votre logiciel (vous saurez exactement quels sont les deux DB concernés (communs + app_spécifiques) si vous savez quelle application vous allez toucher et vice versa.

Dans notre entreprise, nous avons utilisé une database distincte par application, avec des references de bases de données croisées pour la petite quantité d'informations partagées et un server lié occasionnel. Cela a bien fonctionné avec des environnements de développement, de mise en scène, de construction et de production.

Pour les users, toute notre base d'users est sur Windows. Nous utilisons Active Directory pour gérer les users avec des references d'application à des groupes, de sorte que les applications n'ont pas à gérer les users, ce qui est bien. Nous n'avons pas centralisé la gestion de groupe, c'est-à-dire que chaque application a des tables pour les groupes et la security, ce qui n'est pas très agréable mais qui fonctionne.

Je reorderais, si vos applications sont vraiment différentes, d'avoir une database par application. Avec le recul, la database centrale partagée pour les users semble également exploitable.

Vous pouvez utiliser des triggersurs pour l'intégrité référentielle de database croisée:

Créez un server lié au server qui contient la database que vous souhaitez referencer. Utilisez ensuite la dénomination en 4 parties pour referencer la table dans la database distante qui contient datatables de reference. Ensuite, mettez ceci dans l'insert et mettez à jour les sortingggers sur la table.

EXEMPLE (suppose des insertions sur une seule ligne et des mises à jour):

 DECLARE @ref (datatype appropriate to your field) SELECT @ref = refField FROM inserted IF NOT EXISTS (SELECT * FROM referenceserver.refDB.dbo.refTable WHERE refField = @ref) BEGIN RAISERROR(...) ROLLBACK TRAN END 

Pour faire des insertions et des mises à jour de plusieurs lignes, vous pouvez joindre les tables sur le champ de reference, mais cela peut être très lent.

Je pense que la réponse à cette question dépend entièrement de vos besoins non fonctionnels. Si vous concevez une application qui devra un jour être déployée sur des centaines de nœuds, vous devez concevoir votre database de manière à ce que le cas échéant, elle puisse être mise à l'échelle horizontalement. Si d'autre part cette application doit être utilisée par une main pleine d'users et peut avoir une courte durée de conservation, alors vous approchez sera différent. J'ai récemment écouté un podcast sur la façon dont l'architecture d'EBAY est mise en place, http://www.se-radio.net/podcast/2008-09/episode-109-ebay039s-architecture-principles-randy-shoup , et ils ont une database par stream d'application et ils utilisent la partition pour split les tables entre les nœuds physiques. Maintenant, leurs exigences non fonctionnelles sont que le système est disponible 24 heures sur 24, 7 jours sur 7, est rapide, peut prendre en charge des milliers d'users et ne perd aucune donnée importante. EBAY fait des millions de livres et peut donc soutenir l'effort que cela prend pour développer et maintenir.

Quoi qu'il en soit, cela ne répond pas à votre question 🙂 mon opinion du personnel serait de s'assurer que vos exigences non fonctionnelles ont été documentées et signées par quelqu'un. De cette façon, vous pouvez décider de la meilleure architecture. Je serais tenté de faire en sorte que chaque application utilise sa propre database et une database centrale pour datatables partagées. Et j'essaierais de minimiser les dependencies entre eux, ce qui, je suis sûr, n'est pas facile ou vous l'auriez fait :), mais j'essayerais aussi de ne pas avoir à produire une sorte de logiciel middle ware pour garder les tables Synchronisation car cela pourrait créer des maux de tête pour vous.

À la fin de la journée, vous devez mettre votre système en marche et les gars avec les cheveux pointus ne donneront pas un singe chuff sur la façon dont votre design est cool.

Nous sums allés split la database, et avoir une database commune pour toutes les tables partagées. Grâce à eux tous sur l'instance de sauvegarde SQL Server, cela n'a pas affecté le coût d'exécution des requêtes sur plusieurs bases de données.

La key de la réplication pour nous était que le server entier était sur une machine virtuelle (VM), donc pour la réplication pour créer des environnements Dev / Test, le support informatique créerait simplement une copy de cette image et restituerait des copys supplémentaires si nécessaire.