我们正在（重新）设计一个公司信息系统。对于数据库设计，我们正在探索以下选项：
[选项 1->] 一个包含所有内容的 CompanyBigDatabase，
[选项 2->] 公司内的多个数据库（例如 HRD_DB、FinanceDB、MarketingDB），然后通过一层应用程序进行同步。EmployeeTable 归 HRD 所有，如果 Finance 想引用员工，它会通过 Web 服务从 HRD_DB 查询 EmployeeTable。
最佳做法是什么？有什么好处和坏处？我们希望它具有高可用性并且相当可靠。选项 1 是否需要集群和全部？大公司和大学（如丰田、三星、斯坦福大学、麻省理工学院……）总是选择选项 1 吗？
我查看了许多数据库教科书，但找不到关于该主题的充分解释。
欢迎任何想法、提示、链接或建议。谢谢。
我已经做了 20 年这种类型的工作。企业架构是用来描述这一点的一个术语。如果您在真实的企业场景中问这个问题，我建议您获得建议。如果这是一个单一的问题，有很多事情需要考虑：
整个方法论都是为了支持这样做的项目而编写的。您最终可以得到变量的许多答案。即使就如何衡量特征和结果达成一致也很困难。
这是一个巨大的问题，你可以写一本书。
这就像一个 2 段的问题，我看到 10 个人花了一个月的时间把一个商业案例放在一起做 X。那只是成本计算和计划各种选项。没有选择最终的方法。
所以我没有直接回答你的问题......我的朋友是一个严肃的研究项目，而不是真正的 StackOverflow 问题。
没有单一的答案。这取决于许多其他因素，例如数据库负载、应用程序架构、可伸缩性等。我的建议是从最简单的方式（单个数据库）开始，并根据需要进行更改。
单一数据库有它的优点：更简单的连接、参照完整性、单一备份。仅当您有正当理由/需要时才分开数据。
特别是数据库和一般计算有一个一般原则，即每个数据项都应该有一个单一的权威来源。
将此扩展到数据集，一旦您拥有多个客户列表、多个项目列表、多个电子邮件地址，您很快就会陷入不确定性的泥潭，然后需要商业智能解决方案来解决所有这些问题。
现在，从历史角度来看，我是一名商业智能小伙子，但我会是第一个说这不是您想要走的道路，因为营销和客户无法决定“客户”的定义。您这样做是因为您的规范化 OLTP 系统无法轻松计算昨天、上周和去年有多少客户。
他们也不应该这样做，因为那样他们就有可能牺牲自己的真正目的——维护贵公司所在“数据世界”的高性能、高完整性的持久存储。
所以换句话说，单一数据库方法本身就具有数据完整性，你真的不想在没有数据完整性的公司工作。作为一名商业智能从业者，我可以告诉你，这是一个可怕的地方。
另一方面，您将遇到实际情况，由于应用程序供应商的限制等原因，您必须拥有单独的系统，在这种情况下，问题就变成了保持数据尽可能紧密耦合和元数据管理（呃）其中公司同意什么数据在什么位置有什么意义。
在我看来，将数据库规范化并根据部门在公司范围内拥有多个数据库会更合适。这将允许您在存储、检索和更新信息方面更有效地管理数据，并根据部门类型或用户类型为用户提供访问权限。您还可以提供数据库的不同视图。管理数据会容易得多。
两者都会起作用，而其他决定将主要影响您的规范。在某种程度上，您的问题可以描述为“我应该走 ERP 路径还是 SAAS 路径”？我认为这说明现在大多数系统都倾向于 SAAS。
您将如何管理应用程序？如果它们将在不同时间更新，则单独的数据库更有意义。（SAAS 路径）。另一方面，拥有一个要连接的数据库、一个授权系统、一个查找详细信息的地方、一个备份的地方等似乎降低了技术领域的复杂性。但是不允许将影响业务某一部分的决策与业务的其他部分分开考虑
一旦涉及到业务，试图让每个部门都同意升级的时间可能会很糟糕。具有一定程度的抽象性，因此您只需让一个部门在更新其堆栈部分之前进行调整，这在未来几年具有真正的优势。如果您的 Web 服务是健壮的并且不会随每个版本而改变，那么这可能是一个更容易的路径。
不要忘记您可以查看其他数据库中的数据。
至于你关于大多数大公司如何运作的问题；通常是大系统和小系统的错误混搭，这些系统有时相互通信，有时不相互通信，而且经常重复数据。话虽如此，重复数据是一个真正的问题；总是有一个权威的来源和副本（或者更好的是只有一个副本）。我在许多企业中看到的一种行之有效的方法是让一个地方的细节可以被 CRUDed（创建、检索、更新和删除）和许多可以读取的地方。
实际上，这个设计决策与可用性和可靠性几乎没有关系。这往往来自良好的设计（简单性、了解事物的位置等）良好的实践（良好的发布实践、管理实践、备份、智能冗余等）和花钱。不是因为拥有一个或多个系统。