数据库架构，数据库拆分

Question

我遇到了DB架构，对我来说感觉不对。这是一个小型的开发团队......我很感激对此设计的任何看法。

这是对系统的简化描述。所有第三个NF数据库（客户，会计，费率，曝光）

我们有4个普通表格DB​​：

•客户端数据库：维护客户端＆amp;组织信息

•评级数据库：从第三方系统获取汇率

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

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

我们有以下数据库用于数据汇总

• SQL Server Analysis Services ：Star Schema

• Cube

数据库拆分： 我们的4个数据库（客户端，评估，曝光，会计）是4个SQL Server，但它们都是在同一台物理服务器上运行。这些数据库需要来自彼此的数据，例如我们有一个在所有数据库中使用的组织表......或者其他数据库中需要费率。

Analysis Services： 我们有一个星型模式和Analysis Services。我的理解是 Data Vault 可以用作生成Start Schema的源....但是我们没有将 Data Vault 用于此目的。我们使用SSIS直接从客户端，费率，曝光和会计数据库中读取数据，并直接填充启动模式。

问题：

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

2. 是否有一个很好的资源/博客来解释分割数据库的好主意？

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

Answer 1

某事是否是个好主意是一个意见问题。更重要的是权衡取舍的问题，在这里我可以讨论这些。

在部门之间拆分数据库可以让部门在决定其域模型时拥有更大的自由度。 DDD学派的一个有效见解是，团队形成有限的语境，可能会以略微不同于其他语言的方式使用词汇。如果给各个团队更灵活地决定他们自己的术语和数据模型是一件好事，那就是这个。

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

我认为复制数据往往会违反btw划分的有限上下文优势，这是一个警告。但这是自治与绩效之间的权衡。

还需要考虑其他一些事项：

1. 链接服务器是否比数据保险库更好？
2. 目标数据库控制的某种ETL会更好吗？

Answer 2

设计跨域边界的解决方案是一个共同的挑战。如果每个域对象都有一个数据库，那么一切都会相互依赖;如果你有很多独立的数据库，你必须处理跨域查询。

最新的思考是micro services和CQRS的概念。可以说，您的设计是此设计解决方案的原始形式，其中包含数据保险库＆＃34;担任经纪人。

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