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