组织在多个部门和应用程序之间共享关键数据有哪些好方法？
举一个例子，假设有一个主应用程序和数据库来管理客户数据。组织中有十个其他应用程序和数据库读取该数据并将其与自己的数据相关联。目前，这种数据共享是通过混合数据库（DB）链接，物化视图，触发器，登台表，重新输入密钥信息，Web服务等完成的。
有没有其他好方法可以共享数据？而且，您的方法与上述问题相比如何：
请记住，共享客户数据的使用方式很多，从简单的单记录查询到复杂的，多谓词，多排序，与存储在不同数据库中的其他组织数据的连接。
感谢您的建议和建议......
答案 0 :(得分：6)
答案 1 :(得分：4)
这绝对不是一个全面的答复。对不起，对于我的长篇文章，我希望它会增加在这里提出的想法。
我对你提到的一些方面有一些看法。
duplicate data
根据我的经验，这通常是部门化或专业化的副作用。一个部门开创了某些数据的集合，这些数据被其他专业团体认为是有用的。由于它们与其他数据集合混合在一起并不具有对该数据的唯一访问权限，因此为了利用它们，它们也开始收集/存储数据，固有地使其复制。这个问题永远不会消失，就像重构代码和删除重复一样需要不断努力，需要不断地为重复访问，存储和修改提供重复数据。
well-defined interfaces
大多数接口的定义都是为了保持其他约束。但是，我们只是习惯于摆脱先前定义的接口所带来的限制。再一次是连续重构的案例。
tight coupling vs loose coupling
如果有的话，大多数软件都会受到这个问题的困扰。考虑到我们所面临的时间限制，紧耦合通常是有利解决方案的结果。松耦合会产生一定程度的复杂性，当我们想要完成任务时，我们不喜欢这种复杂性。网络服务的口头禅已经进行了多年，我还没有看到一个完全缓解这一点的解决方案的好例子
architectural simplification
对我来说，这是解决你在问题中提到的所有问题的关键。 SIP vs 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可以为这些问题提供灵丹妙药。
答案 2 :(得分：1)
为了解决其中的一些问题，我喜欢中央“数据中心”的概念。数据中心代表特定实体的“单一事实来源”，但仅存储ID，没有名称等信息。事实上，它只存储ID映射 - 例如，这些映射将系统A中的客户ID映射到系统B中的客户编号，以及系统C中的客户编号。系统之间的接口使用集线器来了解如何将一个系统中的信息与另一个系统中的信息相关联。
这就像一个中心翻译;而不是必须编写用于从A-> B，A-> C和B-> C映射的特定代码，随着您添加更多系统，其出勤率呈指数增长，您只需要转换为/来自集线器：A-＆gt; Hub，B-＆gt; Hub，C-＆gt; Hub，D-＆gt; Hub等。