我遇到了DB体系结构，这对我来说不合适。这是针对一小群开发人员...我感谢对此设计的任何意见。
这是对系统的简化描述。所有第三个NF数据库（客户，会计，费率，曝光）
我们有4种正常形式DB：
•客户端DB ：维护客户端＆amp;组织信息
•费率db ：从第三方系统获取汇率
•曝光DB ：联系第三方系统以获取我们的银行帐户和贸易信息
•会计DB ：有关财务风险和预测的进一步计算
我们有以下数据库用于数据围墙
• SQL Server Analysis服务服务：Star Schema
• cube
数据库拆分：我们的4个数据库（ client ， rate ，暴露，会计）是分数4 SQL服务器，但它们都是在同一物理服务器上运行。这些数据库需要彼此的数据，例如，我们有一个在所有DBS中使用的组织表，或其他DBS中都需要速率。
分析服务：我们有星形架构和分析服务。我的理解是，数据库可以用作生成启动架构的来源…。但是，我们并未将我们的 Data Vault 用于此目的。我们使用SSIS直接从客户端，速率，曝光和会计DBS读取数据，并直接填充启动模式。
问题：
-
当我们需要在这些拆分数据库中使用数据时，将数据库分解一个好主意？
-
是否有一个很好的来源/博客可以解释何时分解数据库的好主意？
-
将表从源数据库复制到目标数据库是一个好的解决方案吗？我觉得交叉数据库查询比将如此多的表复制到多个dba中要简单和高效。
是否有一个好主意是一个意见问题。什么是折衷的问题，我可以在这里讨论这些问题。
部门之间的数据库使部门在决定其领域模型方面具有更大的自由度。DDD思想流派的有效见解之一是，团队形成有界环境，这些环境可能会以与其他方式略有不同的方式使用词汇。如果给各个团队在决定自己的术语和数据模型方面具有更大的灵活性是一件积极的事情，那就是这样做的。
另一方面，有许多性能弊端。每个系统对每个数据库中的数据分布了解较少，因此不太有效计划。跨节点连接始终昂贵。因此，您也会得到一些真正的缺点。
我认为复制数据倾向于与BTW部门的有限上下文优势作用，这是一个警告。但这是自主和绩效之间的权衡。
其他几件事要考虑：
- 链接服务器会比数据保险库更好吗？
- 目标数据库控制的某种ETL会更好吗？
设计跨域边界的解决方案存在共同的挑战。如果您对每个域对象都有一个数据库，则一切都将彼此依赖；如果您有很多独立的数据库，则必须处理跨域查询。
对此的最新想法是微服务和CQR的概念。可以说，您的设计是该设计解决方案的一种原始形式，"数据库"充当经纪人。
微服务体系结构的决定"独立性比效率更重要"。每个微服务（以及基础数据存储）都可以做有意义的事情，并以自己的速度移动而不必担心依赖关系。价格是一个更复杂的解决方案，尤其是在处理数据依赖性时。