多个应用程序使用一个数据库？答案

【问题标题】：Multiple application using one database?多个应用程序使用一个数据库？
【发布时间】：2010-08-13 17:30:13
【问题描述】：

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

1) 无论如何，我的问题是我是否要让所有应用程序都只使用 1 个数据库！我对可扩展性有什么问题吗？或者这样做有什么其他问题吗？有1个数据库更好吗？ ?还是最坏的？

2) 还是应该让每个应用程序都有自己的数据库，然后使用 Web 服务在应用程序之间共享公用表？

【问题讨论】：

可能重复[单个或多个数据库](stackoverflow.com/questions/1676552/…)

标签： sql-server database

【解决方案1】：

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

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

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

如今，通过将数据库设为“应用程序私有”，一代互联网程序员正在重现 1960 年代已解决的相同问题。

只是我的一个想法，没有什么真正重要的。

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

【讨论】：

你有什么实际的解决办法吗？
不需要太多的字里行间阅读技巧就能看出答案就在每个单词中。
好的，抱歉看不到。

【解决方案2】：

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

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

整个冒险中最糟糕的部分可能是您将添加到应用程序集中的不必要的复杂性。毕竟，编程不是线性的，简单地添加一个表进行交互会使您的整体复杂性增加一倍以上。

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

我很理解您希望将资源合并到一个公共位置的愿望，但我认为在这种情况下，您将面临更多的困难。我只是觉得不值得。

响应您的编辑...我会选择选项 (2)。

【讨论】：

创建共享服务以与常用表交互的好处是您可以强制执行任何标准化的业务逻辑要求（例如工资与帐户一致等），否则应用程序可以有效地相互通信通过没有任何强制服务逻辑的数据库。

【解决方案3】：

不要创建单独的数据库。然后，您将面临一场噩梦，事情将变得不同步。人们在不同的系统中会有不同的名字和身份，这将是你见过的最糟糕的噩梦。一个系统中的 Dup 将与其他系统中的一个人匹配，从而创建报告问题。在试图让不同的系统匹配时仅仅编写报告将是令人讨厌的。而是计划可扩展性。了解如何对数据进行分区。

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

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

【讨论】：

这就是你拥有微服务的原因。如果需要共享数据，那么让多个应用程序与数据库通信并不是最好的方法。这会产生很多耦合。最好有一个向该数据库公开 api 的微服务。这样所有这些应用程序都可以使用服务而不是数据库。
@vpassapera，不，他们不能都这样做。有时您不需要通过像通过 SSIS 导入 16,000,000 条记录那样的服务。将其作为服务运行将是极端愚蠢的。有时您需要编写一个脚本来修复数据，例如当客户端 A 的所有数据需要转换到客户端 B 时，因为客户端 B 购买了客户端 A。假设没有人会直接或外部访问数据库是愚蠢的您的服务或微服务。
迁移数据库与让一堆不同的应用程序主动使用实时数据库（例如写入和读取）不同。你在这里玩“没有真正的苏格兰人”的游戏（例如移动球门柱）。事实上，让其他应用程序直接访问您的数据库是愚蠢的。网上有很多例子和文章表明你是多么的错误。我建议你做一些研究。
另外，让我为上面的内容指定，报告和 ETL 不是一回事。任何 BA 都不应该创建新记录，如果他们需要非规范化信息，则有很多途径可以走，例如视图。从开发人员的角度来看，您完全不正确。

【解决方案4】：

即使您有一个数据库，您仍然可以使用SCHEMAS 来分隔用户对象，然后您也可以让用户只访问他们的架构而不是其他任何人的架构。在此处阅读架构：http://msdn.microsoft.com/en-us/library/ms190387.aspx

【讨论】：

【解决方案5】：

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

Blogger（谷歌应用）就是一个很好的例子。没有一个客户有权要求只为他们提供一项功能，因此博主很可能会将所有内容都放入一个架构/一个数据库中。

【讨论】：

Blogger 只是一个大数据库？顺便说一句，SO 只是 1 个大数据库，不是吗？
就像我最初所说的，“最有可能”。 SO 引擎和模式至少在 3 个 DB 中，一个用于 SO，一个用于旧堆栈交换，一个用于新堆栈交换，这是合乎逻辑的，因为每个数据库都有不同的客户集和不同的推动它们发展的力量。跨度>

【解决方案6】：

您提出问题的最佳方式是继续“数据库优先”的方法。使用单一数据库并缓解由于许多应用程序使用同一数据库这一事实而产生的问题：

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

您提出问题的方式也是如此：您觉得这种设计有些不对劲，这是真的。但这取决于该系统的短期/长期要求/期望，并且未在此问题中提供。

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

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

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

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

附：看看 DDD 的概念。它对这个问题有深入的了解。

【讨论】：

【解决方案7】：

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

有些东西，即使它们共享一个共同的结构，也需要出于某种业务原因进行分离。由于已明确说明这是一种业务需求，因此在一个数据库中更容易还是在多个数据库中更容易并不重要。

不过，有些事情属于灰色地带。每个单位都必须与“客户”打交道。这应该在共享数据库中吗？可能还有其他人。看起来这些东西有很多共同点，你真的很想将它们存储在一个数据库中。

根据个人经验：不要。独立的业务部门以不同的方式考虑这些事情中的每一个，并且适应所有这些差异可能会使您的表成为维护的噩梦。如果您想要一个可以存储所有业务数据的数据仓库，那可能是个好主意，但实际的日常运营数据可能应该存储在单独的数据库中，以尽可能简化维护和使用。

【讨论】：

【解决方案8】：

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

【讨论】：