主数据管理 - 数据冗余答案

【问题标题】：Master Data Management - Data redundance主数据管理 - 数据冗余
【发布时间】：2011-01-17 09:00:31
【问题描述】：

我目前正在开发一个系统，该系统包含所有相关的主数据，例如客户或有关我们系统环境中存在的操作系统的信息。分配给这些实体的 ID 在企业内是唯一的。当某些系统存储例如客户相关数据，它还必须保存客户的主数据ID。主数据系统基于.Net和MSSQL 2005。

我倾向于使用没有的方法。 1 因为我认为最好将其他系统从 MDM 解决方案中分离出来（关注点分离）。由于 MDM 解决方案可以保存的客户实体数据比我在其他只需要客户姓名的系统中需要的数据多得多。选项 3 是可能的，但 Web 服务可能会大大降低操作系统的速度。你怎么看？

【问题讨论】：

【解决方案1】：

这会带来数据不同步的高风险，然后试图解开它会让人头疼。
这是一个可行的选择，但您必须维护一套体面的程序集供人们使用。这是一项非常重要的任务，因为它们需要健壮、有据可查、拥有可用的 API 以及一些合理的发布管理，就像您对任何 3rd 方框架所期望的一样。根据我的经验，这通常比正常的 LOB 开发实践更严格。
我要说的是要走的路。面向服务的架构允许其他人访问数据，但让他们可以灵活地访问/使用数据。

正如您所说，性能可能是决定因素 - 在这种情况下，1 与 3 结合可能是最好的。即本地副本仅被视为缓存数据，而不是可靠的最新副本。应用程序可以快速检查主数据库以查看本地缓存是否仍然有效（很像 HTTP 土地中的 HEAD 请求），然后使用本地数据或从主数据库刷新它。

【讨论】：

【解决方案2】：

方案一的优缺点是：

优点： - 更快的响应时间（相对于在每次操作时都必须咨询 Master，你可以缓存一些东西来缓解这种情况） - 即使Master暂时不可用，您的卫星系统也可以工作。

缺点： - 您有使用过时数据的风险（如果您在午夜进行 ETL 刷新，则在下一个午夜周期之前您不会获得任何新的或更新的记录） - 当然，您不能让卫星接触到 MDM 的任何本地副本（双向对齐，尤其是多个不同的卫星会成为一场噩梦）。

所以根据具体情况，解决方案 1 可能没问题。我宁愿每次都去查询大师（再次，可能会缓存一段时间的答案），但这更多是个人喜好。

【讨论】：