多个应用使用一个数据库？

Question

Think Design：我有许多共享相同用户数据库的应用程序！其他表也是共享的，例如用户活动日志，购买等

1）无论如何我的问题是，如果我要使所有应用程序只使用1个数据库的一切！我可以在扩展性方面遇到任何问题吗？或者这样做的任何其他问题？拥有1个数据库更好吗？ ？还是最糟糕的？

2）或者我应该让每个应用程序都拥有自己的数据库，然后使用Web服务来共享应用程序之间的公共表？

Answer 1

“或者我应该让每个应用程序都有自己的数据库，”

在20世纪50年代，每个应用程序都有自己的私有文件集。大约十年后，一些聪明人开始观察到那些“appliation-private files”中的某些数据元素实际上是重复信息。客户名称遍布各处，销售点信息在整个地方都是重复的等等。

数据库技术是由更聪明的人发明来解决这个问题的。

现在，通过将数据库设为“应用程序私有”，互联网程序员的产生正在复活1960年代已经解决的同样问题。

只是想到我的，没什么重要的。

“那些忘记历史的人注定要重蹈覆辙”。 （这不是我的）

的想法

Answer 2

您访问共享资源的进程越多，就越有可能进入扩展/性能和计时问题。

即使您的应用程序很小，我也会建议不要这样做。

整个合资企业中最糟糕的部分可能是您将添加到应用程序集中的不必要的复杂性。毕竟，编程不是线性的，只需添加一个表进行交互，就会使整体复杂性增加一倍以上。

至少，创建一个服务以与常用表进行交互，并让您的应用程序通过该服务发出请求。

我同情你将资源合并到一个共同的位置的愿望，但我认为在这种情况下，你将为自己设置更多的困难。我认为这不值得。

回应你的编辑...我会选择（2）。

Answer 3

不要创建单独的数据库。那么你将有一个噩梦来维持，事情将会失去同步。人们在不同的系统中会有不同的名字和ID，这将是你见过的最糟糕的噩梦。一个系统中的Dups将与其他人中的一个人匹配，从而产生报告问题。只是在试图让不同的系统匹配时编写报告将是令人讨厌的。相反，计划可扩展性。了解如何分区数据。

如果您有多个应用程序访问同一个数据库，请确保数据库维护数据完整性而不是任何应用程序！这是至关重要的，否则某些应用程序可能不知道维护其他人需要的某些事情，并且您将需要清理数据完整性灾难。使用真正的PK和Fk约束，定义默认值，使用正确的数据类型，以便无法输入无效日期等。

不允许开发人员在未经数据库专家批准的情况下更改数据库结构，而数据库专家知道其他应用程序可能会受到更改的影响。确保第一次学习如何编写高性能代码，因为您将使用代码影响其他应用程序。

Answer 4

即使你有一个数据库，你仍然可以使用SCHEMAS来分隔用户对象，那么你也可以让用户只访问他们的模式，而不是任何其他人的模式。在这里阅读Schema：http://msdn.microsoft.com/en-us/library/ms190387.aspx

Answer 5

应用程序倾向于复制创建它们的组织。如果数据库有两个客户，您可能会发现自己要求进行更改，这可能会破坏其他客户使用的功能。因此，如果应用程序有一个客户但有几个不同的模式，您可能希望将它们放在一个数据库中。如果应用程序有许多客户，您可能希望将它们分离到不同的数据库，即使模式大致相同 - 如果您需要支持为一个用户而不是另一个用户进化应用程序的可能性。

Blogger（谷歌应用）就是一个很好的例子。没有一个客户能够专门为他们要求一个功能，所以博客很可能将所有内容都放在一个模式/一个数据库中。

Answer 6

有些事情在您的业务中是通用的。这些东西包括用户，用户活动/审核日志等。这些可以很容易地在一个数据库中维护。

有些事情，即使它们共享一个共同的结构，由于某些商业原因需要分开。由于有一个声明的原因，这是一个业务需求，它是否更容易在一个数据库中执行，而不是在多个数据库中执行。

但是，有些事情属于灰色地带。每个单位都必须处理“客户”。这应该在共享数据库中吗？也可能有其他人。看起来这些东西共享如此多的共性，你真的想将它们存储在一个数据库中。

从个人经验来看：不要。不同的业务部门对这些事情的看法不同，容纳所有这些差异可能会使您的表格成为维护的噩梦。如果您想要一个可以存储所有业务数据的数据仓库，这可能是一个好主意，但实际的日常操作数据可能应该存储在不同的数据库中，以使维护和使用尽可能简单。

Answer 7

如何围绕用户数据库编写应用程序包装，让所有其他应用程序使用该服务而不是数据库来获取用户信息？

Answer 8

您提出问题的最佳方式是继续“数据库优先”的方法。使用单个数据库并缓解由于有许多应用使用同一数据库而造成的问题：

• 严格的数据库架构和数据库约束
• 独立的单机数据库管理，数据库发布流程
• 咨询，将架构更改通知所有应用/开发者，阻止他们更改架构
• 鼓励开发者使用数据库事务，因为他们的应用无法控制操作完整性
• 有些人可能会建议将代码移至数据库（例如存储过程），但这是有争议的
• 如果事情变得复杂，那么大多数关系数据库都有模式，可在数据库级别提供进一步的数据分离

同样是你提出问题的方式：你觉得这个设计有些不对劲，这是真的。但这取决于对该系统的短期/长期要求/期望，本问题未提供。

我使用这个一般的“经验法则”来做出决定：当我们面临需要解决的业务问题时，我们（我或团队）首先想到的是什么：

• 如果是表、字段和关系 - 使用单个数据库，最好使用单个应用程序。以后在适当的时候和仍然需要时从那里发展。
• 如果是业务运营、业务工作流、业务服务，那么沿着这条路走下去，并在需要的地方附加专用数据库。

没有任何数据库引擎或编程语言可以解决设计不佳的系统。如果你做对了那部分，你选择的工具是第二优先的。做你和你的团队最擅长的事情。

我知道这篇文章很旧，但我决定在这里加两分钱。

附言看看 DDD 概念。它深入探讨了这个问题。