J'ai trois applications différentes, ils partagent tous l'aspect ASP.NET de la base de données et, presque, ils ne partageront rien d'autre.
Dois-je avoir une base de données séparée pour chacune des applications ou suffirais-t-on?
Toutes les tables d'application sont préfixées, de sorte que ce ne serait pas un problème d'intégration. Bien que je me demandais s'il y aurait des problèmes de performance, ou si les trois candidatures partagent la même base de données seraient une sorte de grave erreur.
Les applications en question sont trois applications Web, le "site principal", un forum et un suivi de bogues. Je me demande si cela est viable car l'intégration pourrait être plus facile si j'avais une base de données unique. Par exemple, le suiveur de bugs enregistre les tables d'adhésion ASP.NET dans sa connexion DB, et elle crée même un utilisateur "admin", où la DB est en fait supposée contenir les tables d'adhésion serait le "site principal". < / p>
MISE À JOUR: J'ai ajouté une génération à cette question puisque les réponses semblent avoir de jolies opinions fractionnées sur la question de savoir si je devrais ou non utiliser plusieurs bases de données pour différentes applications qui ne partagent que les fournisseurs d'adhésion.
7 Réponses :
J'ai toujours trouvé qu'il serait préférable d'avoir plus de bases de données afin qu'elle soit plus facile de:
Je vais réellement aller avec quatre bases de données. Une base de données d'adhésion, puis une pour chaque application (si l'adhésion est vraiment partagée). Cela vous permettra également de verrouiller la sécurité entre les applications.
Regarder votre question plus proche ... vous dites que les données «probablement ne seront probablement pas partagées» ... Beaucoup de vos questions joignent-elles des tables avec l'adhésion? Si tel est le cas, peut être plus facile si elles sont dans la même base de données. Toutefois, si vous allez avec une approche davantage basée sur l'entité, je penserais que vous seriez toujours mieux avec plusieurs bases de données. Vous voudrez peut-être même regarder quelque chose comme une base de données LDAP ou un autre type de mise en cache pour votre base de données d'adhésion pour accélérer les choses.
Cela aurait été ma raison de ne pas fusionner les bases de données et même d'avoir un quatrième pour l'adhésion seulement. Mais combien puis-je étirer des bases de données? Je veux dire, c'est est le même site web.
Selon votre plate-forme ... généralement, vous le ferez en se connectant via une API à l'autre base de données (préférées sur des vues liées), ou simplement qualifiant pleinement votre nom de serveur et de base de données avant que vous appelle l'appel. Par exemple, j'ai des méthodes spécifiques que j'appelle pour obtenir et définir des informations d'adhésion sur mon site sur cette base de données (également une pour la journalisation dont j'ai besoin), ces commandes utilisent un paramètre de connexion pré-réglé différent en interne afin qu'ils savent où aller. De cette façon, je peux le changer à un serveur différent ou modifier la configuration de la base de données et avoir un point de maintenance.
J'aime l'idée de l'adhésion distincte DB. Si ces données d'adhésion doivent être disponibles d'une certaine manière dans les autres bases de données, que pensez-vous de l'idée de reproduire les données d'adhésion aux trois autres?
Chaque cas est différent, mais je tiendrais généralement les données de base dans la DB d'adhésion et l'étendre dans d'autres tables spécifiques à ces systèmes. Cela relèverait également des meilleures pratiques pour EF et vous permettrait de faire une entité d'adhésion de base avec les détails qui sont hérités du noyau.
juste mon inclination: bien que les trois applications ne partagent pas beaucoup (pas , de toute façon: mais que se passe-t-il quand un Post Forum veut faire référence à un rapport de bogue?), ils appartiennent tous à la même chose "Système", pour ainsi dire.
Je mettrais certainement toutes les tables dans une seule base de données.
Vous devez utiliser la même base de données que si vous avez un besoin actuel de les placer dans des bases de données distinctes - toutefois, vous devez archiver votre système afin que vous puissiez déplacer les données dans une base de données séparée si nécessaire.
En pratique, cela signifie que vous devez conserver des procédures SQL fonctionnant la plus petite quantité de données possibles - c'est-à-dire que vous n'avez pas de Procs stockés à plusieurs pas qui font beaucoup d'actions distinctes. Avoir des USPS séparés et appelez chacun de code.
raisons d'utiliser des bases de données distinctes:
1) Données non liées - Les données du groupe interdépendantes - Andoince Base Bases vont au-delà d'une certaine complexité, cherchent à séparer les blocs de données connexes dans des bases de données distinctes afin de simplifier.
2) Les données qui sont d'une importance capitale (par exemple des détails personnels) doivent être séparées pour permettre des mesures de sécurité plus importantes: par exemple. Sélection de ces données de développeurs
3) ou une importance inférieure (p. ex. Informations de journalisation) - cela n'a probablement pas besoin de sauvegarder - et s'il est particulièrement volumineux, vous ne voulez probablement pas que cela augmente le temps nécessaire pour sauvegarder la base de données du site principal.
4) Utilisé par les applications vivant sur différents serveurs à différents endroits. Bien évidemment, vous souhaitez que les données du site soient aussi proches que possible de la demande consommatrice.
Sans vraiment connaître la taille et l'échelle de votre système, difficiles à donner pleinement d'avis, si ce n'est que votre propre site, un DB peut fonctionner pour le moment - si c'est commercial, je disposerais de 4 DBS du mot Go: Adhésion Détails, Forum, Tracker de bogues et trucs connexes de Mainsite.
Ainsi, dans le code, vous auriez un gestionnaire de membres qui ne parle que de la DB des membres, d'un BugManager, d'un forumManager et de tout autre chose ne parlera qu'à la DB du Mainsite. Je ne peux penser à aucune raison pour laquelle vous auriez besoin de ces bases de données vous parler.
Applications séparées = Séparer des bases de données - sauf si vous devez "presser" tout dans un seul dB (par exemple sur un hébergement Web partagé).
+1 pour des sauvegardes / restaurations séparées et la flexibilité pour déplacer la base de données entre serveurs selon les besoins
À mon avis, il est préférable de diviser la base de données pour une flexibilité, une sécurité, une efficacité et une évolutivité accrues.
À l'avenir S'il y a un ajout d'exigence (vous ne savez jamais) qui est commun à toutes les trois applications, il pourrait être un peu difficile à maintenir.
Par exemple: Login de l'utilisateur / trace d'audit pour vos 3 applications.
Cela peut sembler comme je vais errer un peu, mais vous avez-vous pris en compte une autre possibilité, qui séparait toute la fonctionnalité d'authentification / d'adhésion en une application elle-même?
Dans votre description, il semble que vous puissiez ajouter une autre application à l'avenir. Il commencerait à ressembler à un réseau de sites, ce qui ressemble beaucoup à 37signals Web Apps, Google Web Apps ou MSN Web Apps.
Et ainsi, vous pouvez choisir une sorte de service à une seule connexion / connexion. Cette seule application peut offrir des méthodes d'authentification via des services Web ou tout autre mécanisme, il aura sa propre dB pour vous permettre de modifier, de modifier, de sauvegarder et de déplacer sans affecter les autres applications. J'ai moi-même trouvé cette situation plusieurs fois et j'aime donc à quel point il est facile de partager votre connexion Google ou Facebook parmi les applications.
Peut-être que je le vois d'une perspective plus élevée que la vôtre, désolé si c'est le cas. Si ce n'est pas une option, vous pouvez conserver 4 bases de données: 1 pour chaque application et 1 pour le fournisseur d'adhésion, qui a ses propres connexions la plupart du temps.
Bien sûr, cela dépend de la taille de votre empreinte d'applications sur le niveau de DB. 10 tables par application est ok, 150 tables par application rendraient la DB un peu laide pour nous, qui sont une préférence personnelle.
bonne chance avec n'importe quelle option que vous choisissez.
Il y a cependant des descentes, par exemple, il est plus difficile d'écrire une requête pour deux applications à la fois
Je serais peut-être d'accord si vous pouvez m'expliquer pourquoi vous feriez cela ou le contexte de votre pensée.