组织在许多部门和应用程序之间共享关键数据有哪些好方法？
举个例子，假设有一个主要的应用程序和数据库来管理客户数据。组织中还有十个其他应用程序和数据库读取该数据并将其与他们自己的数据相关联。目前，这种数据共享是通过混合使用数据库 (DB) 链接、物化视图、触发器、临时表、重新键入信息、Web 服务等来完成的。
还有其他共享数据的好方法吗？并且，您的方法与上述方法相比如何解决以下问题：
请记住，共享客户数据的使用方式很多，从简单的单记录查询到复杂的、多谓词、多排序、连接存储在不同数据库中的其他组织数据。
感谢您的建议和建议...
我相信你已经看到了这个，“这取决于”。
这取决于一切。A 部门共享客户数据的解决方案可能与 B 部门共享客户数据完全不同。
多年来我最喜欢的概念是“最终一致性”的概念。该术语来自亚马逊谈论分布式系统。
前提是，虽然分布式企业中的数据状态现在可能并不完全一致，但“最终”会如此。
例如，当系统 A 上的客户记录得到更新时，系统 B 的客户数据现在已过时且不匹配。但是，“最终”，来自 A 的记录将通过某些过程发送给 B。因此，最终，这两个实例将匹配。
当您使用单个系统时，您没有“EC”，而是有即时更新、单一“事实来源”，以及通常用于处理竞争条件和冲突的锁定机制。
您的操作越能处理“EC”数据，就越容易分离这些系统。一个简单的例子是销售使用的数据仓库。他们使用 DW 来运行他们的每日报告，但他们直到凌晨才运行他们的报告，并且他们总是查看“昨天”（或更早）的数据。因此，DW 无需实时与日常操作系统完全一致。例如，在营业结束时运行流程并在大型单一更新操作中移动交易和活动的日子是完全可以接受的。
您可以看到此要求如何解决很多问题。事务数据没有争用，不用担心某些报表数据会在统计数据的累积过程中发生变化，因为报表对实时数据库进行了两次单独的查询。白天不需要为了高细节的喋喋不休吸食网络和cpu处理等。
现在，这是 EC 的一个极端、简化和非常粗略的例子。
但是考虑一个像谷歌这样的大型系统。作为搜索的消费者，我们不知道谷歌从何时或多长时间获得一个搜索结果到搜索页面上的位置。1毫秒？1秒？10s？10小时？很容易想象，如果您访问 Google 的西海岸服务器，您可能会得到与访问他们的东海岸服务器不同的搜索结果。这两个实例在任何时候都不是完全一致的。但在很大程度上，它们大多是一致的。对于他们的用例，他们的消费者并没有真正受到滞后和延迟的影响。
考虑电子邮件。A 想向 B 发送消息，但在此过程中，消息通过系统 C、D 和 E 进行路由。每个系统都接受该消息，对其承担全部责任，然后将其交给另一个系统。发件人看到电子邮件正在发送中。接收者并没有真正错过它，因为他们不一定知道它的到来。因此，该消息可能需要很长时间才能通过系统，而无需任何人知道或关心它的速度有多快。
另一方面，A 本来可以和 B 通电话的。“我刚发了，你收到了吗？现在？现在？现在收到？”
因此，存在某种潜在的、隐含的性能和响应水平。最后，“最终”，A 的发件箱与 B 的收件箱匹配。
这些延迟，对陈旧数据的接受，无论是一天前的还是 1-5 秒前的，都是控制系统最终耦合的因素。这个要求越松，耦合就越松，您在设计方面拥有的灵活性就越大。
这对于您的 CPU 中的内核都是正确的。在同一系统上运行的现代、多核、多线程应用程序可以对“相同”数据有不同的看法，只有几微秒的时间过时。如果您的代码可以正确处理可能彼此不一致的数据，那么快乐的一天，它就会拉开。如果不是，您需要特别注意确保您的数据完全一致，使用易失性内存限定或锁定构造等技术。所有这些，以它们的方式，成本性能。
所以，这是基本的考虑。所有其他决定都从这里开始。回答这个问题可以告诉您如何跨机器划分应用程序、共享哪些资源以及如何共享它们。哪些协议和技术可用于移动数据，以及执行传输的处理成本。复制、负载均衡、数据共享等等等等，都是基于这个概念。
编辑，以回应第一条评论。
正确，完全正确。比如说这里的博弈，如果B不能改变客户数据，那么改变客户数据有什么害处呢？你可以“冒险”它在短时间内过时吗？也许您的客户数据输入速度很慢，以至于您可以立即将其从 A 复制到 B。假设更改被放入队列中，由于容量小，很容易被提取（< 1s），但即使它仍然会与原始更改“交易外”，所以有一个小窗口 A 会有B 没有的数据。
现在头脑真的开始旋转了。在“滞后”的那 1 秒内会发生什么，最糟糕的情况是什么。你能围绕它进行工程设计吗？如果您可以设计大约 1 秒的延迟，您可能可以设计大约 5 秒、1 米甚至更长的延迟。您在 B 上实际使用了多少客户数据？也许 B 是一个旨在促进从库存中拣选订单的系统。很难想象还有什么比简单的客户 ID 和名称更重要的东西。只是在组装时大致确定订单的对象。
拣货系统不一定需要在拣货过程结束之前打印出所有的客户信息，到那时订单可能已经转移到另一个可能更新的系统，尤其是运输信息，所以最后，拣货系统几乎不需要任何客户数据。事实上，您可以在拣货订单中嵌入和非规范化客户信息，因此无需或期望稍后进行同步。只要客户 ID 正确（无论如何都不会更改）和名称（更改很少，不值得讨论），这就是您需要的唯一真实参考，并且您的所有选择单在当时都是完全准确的创建。
诀窍在于心态，打破系统并专注于任务所需的基本数据。您不需要的数据不需要复制或同步。人们对非规范化和数据缩减等事情感到恼火，尤其是当他们来自关系数据建模领域时。并且有充分的理由，应该谨慎考虑。但是一旦你去分布式，你已经隐式地去规范化了。哎呀，你现在正在批发复制它。所以，你不妨更聪明一点。
所有这些都可以通过扎实的程序和对工作流程的透彻理解来缓解。识别风险并制定处理它们的政策和程序。
但困难的部分是在一开始就打破与中央数据库的链条，并告诉人们当你拥有一个单一的、中央的、完美的信息存储时，他们不能像他们期望的那样“拥有一切”。
这绝对不是一个全面的答复。对不起，对于我的长篇文章，我希望它能增加将在这里提出的想法。
我对你提到的一些方面有一些看法。
duplicate data
根据我的经验，这通常是部门化或专业化的副作用。一个部门率先收集其他专业团体认为有用的某些数据。由于他们没有对这些数据的唯一访问权，因为它与其他数据收集混合在一起，为了利用它，他们也开始收集/存储数据，从而固有地使其重复。这个问题永远不会消失，就像在重构代码和消除重复方面不断努力一样，需要不断地带来重复数据以进行集中访问、存储和修改。
well-defined interfaces
大多数接口的定义都是出于好意，同时牢记其他约束。然而，我们只是习惯于摆脱先前定义的接口所施加的约束。又是一个持续重构的案例。
tight coupling vs loose coupling
如果有的话，大多数软件都受到这个问题的困扰。考虑到我们面临的时间限制，紧密耦合通常是权宜之计的结果。松散耦合会带来一定程度的复杂性，当我们想要完成工作时，我们不喜欢这种复杂性。Web 服务的口头禅已经流传了很多年，我还没有看到一个很好的解决方案示例，可以完全缓解这一点
architectural simplification
对我来说，这是解决你在问题中提到的所有问题的关键。我想到了 SIP 与 H.323 VoIP 的故事。SIP 非常简化，易于构建，而 H.323 像典型的电信标准一样试图设想地球上有关 VoIP 的每一个问题并为其提供解决方案。最终结果是，SIP 增长得更快。成为符合 H.323 的解决方案是一件痛苦的事情。事实上，H.323 合规性是一个巨大的产业。
On a few architectural fads that I have grown up to.
多年来，我开始喜欢 REST 架构，因为它很简单。它提供了对数据的简单独特访问，并易于围绕它构建应用程序。我已经看到企业解决方案遭受的数据复制、隔离和访问比任何其他问题（如性能等）更严重。REST 对我来说是解决其中一些问题的灵丹妙药。
为了解决其中的一些问题，我喜欢中央“数据中心”的概念。数据中心代表特定实体的“单一事实来源”，但只存储 ID，不存储名称等信息。事实上，它只存储 ID 映射 - 例如，这些映射将系统 A 中的客户 ID 映射到系统 B 中的客户编号，以及系统 C 中的客户编号。系统之间的接口使用集线器来了解如何将一个系统中的信息与另一个系统相关联。
这就像一个中心翻译；无需编写从 A->B、A->C 和 B->C 映射的特定代码，随着您添加更多系统，其出勤率呈指数增长，您只需要转换到集线器/从集线器转换：A- >集线器、B->集线器、C->集线器、D->集线器等。