1

我遇到了我觉得不对劲的数据库架构。它适用于一小群开发人员......我将不胜感激有关此设计的任何意见。

这是系统的简化描述。所有 3rd NF 数据库（客户、会计、费率、曝光）

我们有 4 个范式 DB：

• 客户数据库：维护客户和组织信息

• 汇率数据库：从第 3 方系统获取汇率

• Exposure DB：联系第三方系统获取我们的银行账户和交易信息

• 会计数据库：进一步计算财务风险和预测

我们有以下数据库用于数据仓库

• SQL Server 分析服务：星型模式

• 立方体

数据库拆分： 我们的 4 个数据库（Client、Rate、Exposure、Accounting）是拆分数量的 4 个 SQL Server，但它们都运行在同一个物理服务器上。这些数据库需要彼此的数据，例如我们有一个用于所有数据库的组织表……或者其他数据库中需要速率。

分析服务： 我们有星型模式和分析服务。我的理解是Data Vault可以用作生成 Start Schema 的来源……。但我们并没有为此目的使用我们的Data Vault 。我们使用 SSIS 直接从Client、Rate、Exposure 和 Accounting DB 读取数据，并直接填充启动模式。

问题：

  1. 当我们需要使用这些拆分数据库中的数据时，拆分数据库是一个好主意吗？

  2. 是否有一个好的来源/博客来解释什么时候拆分数据库是个好主意？

  3. 将表从源数据库复制到目标数据库是一个好的解决方案吗？我觉得跨数据库查询比将这么多表复制到多个 DBa 中要简单和高效得多。

4

2 回答 2

3

某事是否是一个好主意是一个意见问题。更少的是权衡是什么的问题，在这里我可以讨论这些。

在部门之间拆分数据库使部门在决定他们的领域模型时有更大的自由。DDD 学派的有效见解之一是团队形成有界上下文，这些上下文可能以与其他人略有不同的方式使用词汇。如果让各个团队在决定自己的术语和数据模型方面有更大的灵活性是一件积极的事情，那就是这样做的。

另一方面，存在许多性能缺陷。每个系统对每个数据库中的数据分布了解较少，因此无法有效规划。跨节点连接总是很昂贵。所以你也会得到一些真正的缺点。

我认为复制数据往往会违反除法的有限上下文优势，这是一个警告。但这是自治和性能之间的权衡。

需要考虑的其他几件事：

  1. 链接服务器会是比数据保险库更好的选择吗？
  2. 由目标数据库控制的某种 ETL 会更好吗？
于 2017-09-21T07:32:08.917 回答
1

在设计跨域边界的解决方案时存在一个共同的挑战。如果您有一个包含每个域对象的数据库，那么一切都变得相互依赖；如果你有很多独立的数据库，你必须处理跨域查询。

在这方面最新的思考是微服务和CQRS的概念。可以说，您的设计是这种设计解决方案的原始形式，“数据保险库”充当代理。

微服务架构强制执行的决定是“独立比效率更重要”。每个微服务（和底层数据存储）都可以做有意义的事情，并以自己的速度移动，而不必担心依赖关系。这样做的代价是一个更复杂的解决方案，尤其是在处理数据依赖关系时。

于 2017-09-21T11:05:33.877 回答