我目前正在开发一个系统，其中包含所有相关的主数据，例如客户，或者有关我们系统环境中存在的操作系统的信息。 为这些实体分配的ID在企业中是唯一的。当一些系统存储例如客户相关数据，它也必须保存客户的主数据ID。 主数据系统基于.Net和MSSQL 2005.
现在我的问题是，当使用自己的程序集，数据库等开发另一个使用MDM系统数据的系统时，您是否会将这些数据冗余地存储在其他系统数据库中，创建自己的业务实体（如客户）并从其他数据库（或ETL）的MDM硬编码所需的主数据？这样，另一个系统与MDM分离，但仅存储全局主数据ID。
或者您是否将MDM的程序集集成到其他系统（如果是.Net）并使用MDM的数据层加载全局实体（如客户）？
或者您是否让其他系统创建自己的实体，但是为了检索主数据，您将使用MDM提供的SOAP接口。
我倾向于使用方法号。 1因为我认为最好从MDM解决方案中分离其他系统（关注点分离）。由于MDM解决方案可以保存客户实体的更多数据，而不是在需要客户名称的其他系统中所需的数据。选项3是可能的，但Web服务可能会减慢操作系统的速度。你觉得怎么样？
答案 0 :(得分：5)
这会导致数据失去同步的高风险，然后是一个试图解开数据的重大问题。
这是一个可行的选择，但你必须维护一套体面的程序集供人们使用。这是一项非常重要的任务，因为它们需要健壮，文档齐全，具有可用的API以及一些合理的发布管理，就像您对任何第三方框架的期望一样。根据我的经验，这通常是高于正常LOB开发实践的严格程度。
我要说是要走的路。面向服务的体系结构允许其他人访问数据，但为他们提供访问/使用数据的灵活性。
正如你所说，表现可能是决定因素 - 在这种情况下，1与3结合可能是最好的。即，本地副本仅作为高速缓存数据被查看和处理，而不是可靠的最新副本。应用程序可以与主数据库进行快速检查，以查看本地缓存是否仍然有效（很像HTTP域中的HEAD请求），然后使用本地数据或从主数据库刷新它。
答案 1 :(得分：1)
解决方案1的优点和缺点是：
优点： - 更快的响应时间（相对于每次操作都要咨询Master，你可以缓存一些东西来缓解这种情况） - 即使主人暂时无法使用，您的卫星系统也能正常工作。
缺点： - 您可能会使用过时的数据（如果您在午夜进行ETL刷新，则在下一个午夜周期之前不会获得任何新的或更新的记录） - 当然你不能允许卫星接触MDM的任何本地副本（双向对齐，特别是多个不同的卫星变成了一场噩梦）。
因此，根据具体情况，解决方案1可能没问题。我更愿意每次都去查询大师（再次，可能会在一段时间内缓解答案），但更多的是个人偏好。