我应该为每个应用程序使用一个数据库还是在多个应用程序中共享一个数据库？

我有多个应用程序，其中一些使用来自相同来源的数据。最佳做法（或优点/缺点）是：

• 将数据保留在多个应用程序共享的数据库中

  1. 节省空间，因为只需要一个数据库
  2. 索引复杂化，因为不同的应用程序具有不同的查询需求

• 每天将数据导入每个应用程序数据库

  1. 每个应用程序数据库中存在重复数据，因此使用更多空间
  2. 索引更容易，因为每个应用程序都可以专注于其各自的需求

我可能遗漏了其他优点/缺点，请列出（如果有），在您的工作场所该如何做？

这些天空间很便宜，所以我建议每个应用程序使用一个数据库。

在多个应用程序之间共享一个数据库有一些严重的缺点：

• 使用同一数据库的应用程序越多，遇到性能瓶颈的可能性就越大，并且您无法轻松地按需扩展负载。SQL数据库无法真正扩展。您可以购买更大的机器，但它们无法在集群中很好地扩展！

• 维护和开发成本会增加：如果应用程序需要使用不适合当前任务但必须使用的数据库结构，则开发将变得更加困难。一个应用程序的调整也可能会对其他应用程序产生副作用（“为什么会有这样不必要的触发？？！” /“我们不再需要该数据！”）。当开发人员不知道所有用例时，对于一个应用程序使用一个数据库已经很困难。

• 管理变得更加困难：哪个对象属于哪个应用程序？混乱上升。我必须在哪里寻找资料？允许哪个用户与哪些对象进行交互？我可以授予谁？

• 升级：对于所有使用它的应用程序，您都需要一个最低公分母的版本。这意味着某些应用程序将无法使用强大的功能。您必须坚持使用旧版本。这也增加了开发成本。

• 并发性：您真的可以确定流程之间没有按时间顺序的依赖关系吗？如果一个应用程序修改了过时的数据或首先应由另一应用程序更改过的数据该怎么办？那么在同一张表上同时工作的不同应用程序呢？

与此相比，数据导入/ ETL过程几乎总是非常简单明了。可以根据需要频繁加载数据，因此空间很便宜。您可以独立考虑每个应用程序的可伸缩性，根据需要调整和调整结构，不会出现并发问题。副作用也可以轻松得多。

编辑： 不过，我想指出的是，正如@Saeed所提到的，如果您可以将数据操作封装在通常可用的服务中，那么与多个应用程序共享一个数据库会更容易。只要您不需要原始访问权限，这就是一个很好的方法。

我曾经有过类似的情况。我的问题是要构建3个应用程序，一个用于库存管理，一个用于采购管理，以及一个用于管理用户（即员工）的应用程序。我的建议是不要在每个应用程序上物理破坏数据库，也不在每个应用程序上物理加入数据库。相反，恕我直言，逻辑分离效果更好。

例如，所有3个应用程序都需要使用员工信息。库存和采购系统都使用相同的货物和库存项目信息。

我创建了一个共享数据库，其中存储了用户和商品的信息。然后，我在其之上构建了一个服务层，并在其他应用程序中使用了这些服务。例如，要显示当前在公司中的所有员工的列表，我只需要从服务中调用一个方法，例如GetOnWorkEmployees()。

我还创建了一个用于与用户和商品进行交互的通用UI，这是一个独立的Web应用程序。

因此，除了@Falcon指出的那样，我认为您可以从集中一个数据库中的应用程序之间的通用功能中受益。

如果要使这些应用程序使用相同的数据（例如，相同的产品和客户列表）工作，则将数据库保持在一起。通过分离数据库，您不会获得任何收益。那纯粹是一个“人为”的问题-对于服务器来说，它在磁盘上的仅字节数。它不在乎其1或100数据库。但是，如果您将其拆分，则必须处理数据同步。索引问题带来了一个真正的问题-如果数据库被拆分，则您将花费​​相同数量的处理器时间来维护索引。

如果性能开始成为问题，则将数据库复制到多个服务器以平衡情况。

在您所处的环境中，也许值得不付出代价，但是使用单个数据库更容易维护数据完整性。至少在MS SQL Server中，您不能将外键从一个数据库导入另一个数据库。您可以使用触发器来模拟外键行为，但这并不是特别好。

另外，写操作时，创建数据的本地副本可能很危险。如果AppA和AppB都具有一些共享数据的副本并由AppA更新，则AppB仍将具有旧数据。或者，您将必须设置触发器以使数据保持同步。

曾经有多个网站随着时间的推移而流行。他们使用了单独的数据库，主要是因为托管服务提供商各自仅允许1Gb的存储空间。但！一旦发布了包含所有这些网站的服务，我便开始在这些网站之间进行交易，而最方便的方法是将所有内容最终转移到一个大数据库中。

因此，我优化了数据库结构，并将相关部分压缩到该中央数据库中，但其他所有内容均被排除在外。

我的看法与OOP的范例有某种联系。相似的数据必须存储在一起，因此，如果您构建不同的应用程序，则应为其使用不同的数据库。

在上述情况下，无法避免使用公共数据库，但是请记住，我还在单独的数据库中保留了一些表，这些表不是公共查询的一部分。

此外，如果将它们分开，则它们将更易于备份，数据丢失的机会也更少。如果出现问题并且应用程序相互干扰，则数据库会混乱，并且您基本上不想让您的应用程序遭受这种危险。

总而言之，您可以维护一个用于常见查询的公共数据库，但也可以为每个应用程序保留一个数据库。

您能否详细说明您的应用程序体系结构？

如果您的数据库仅用作数据存储库而没有触发器或业务包代码之类的应用程序逻辑，则最好有一个数据库并将业务级功能封装到使用该数据库执行所有操作的服务中。如果您在数据库模式中有触发器或代码，则使用单个数据库会造成很大的麻烦，这在许多情况下会很麻烦。