oracle - Maximo 的出站集成 : Is there a reason why materialized views are not a suitable choice?

Question

我想要设置从 Maximo 7.6.1.1 到外部系统的出站集成。 Maximo 和外部系统都有 Oracle 12c 数据库。

在外部系统中，我想从 Maximo WORKORDER 表中选择打开的 WO，以进行近实时数据分析。

<小时/>

标准集成选项似乎是:

1. 平面文件
2. XML 文件
3. 接口(interface)表
4. 网络服务

<小时/>

我注意到materialized views通常不被认为是有效的集成选项。

例如，我可以通过 dblink 在外部系统中的 Maximo.WORKORDER 表上创建一个物化 View 。物化 View 可以通过多种不同的方式设置，包括按计划刷新、近乎实时等。

据我所知，物化 View 将是一种相当强大的集成技术。但是，我还没有听说过任何同行使用物化 View 来进行 Maximo 集成。

是否有技术原因导致物化 View 不适合 Maximo 集成？

示例:

两个数据库都需要是最新型号的 Oracle 数据库才能实现物化 View ，但情况并非总是如此。

Answer 1

Oracle 的物化 View 对于数据建模者和数据库设计者来说是一个出色的工具。从字面上看，它们是数据库市场上最好的 MV 实现之一(我的主要经验是使用 Oracle，并且我使用过 SQL Server 和 PostgreSQL:我没有使用过 DB2 或其他数据库)。作为实例化 View ，它们提供了传统 View 的所有功能，但还具有用于构造更高性能、受约束和索引的“表”对象的附加功能。我想人们可以将 MV 视为一张表，其中包含描述其构造和刷新的元数据。

为什么MV没有得到更广泛的应用？

首先(1)，在提到的情况下，访问Maximo，总是存在能够访问专有产品的模式的问题。

其次(2)，MV(或 View )要想成功，就必须正确访问底层数据，这需要对所访问的数据有全面的了解。可以使用 MV 和各种技术来访问此处建议的数据类型，但这可能不是最好的方法(参见下面的 3)。

第三(3)，专有系统中的数据库表是事务和面向过程的数据的动态环境的一部分。所以，保证上面2中MV正确性的需要，也适用于这里。

第四(4)，很可能是无知。我遇到了多少 Oracle 专业人士，他们参加过有关 MV 的类(class)？可能很少(我自己也属于这个群体)。鉴于我刚刚承认的事实，为什么我认为我可以写这篇回复？我想这是因为我的整个职业生涯都与 Oracle 和其他数据库打交道。我曾经遇到过这样的情况:我必须构建事务型 > 数据仓库类型的解决方案，这需要为 MV 获取大量且持续的知识(广泛用于 Oracle 到 Oracle 的复制)。

第五 (5) 扩展 4 是人们对他们最熟悉的工具的痴迷。如果那是桌面或网络 GIS，那么这就是他们所知道的。在生产环境中对数据库的访问往往会受到限制，因此除非存在全栈开发/测试/生产数据库，否则无法访问用于学习的“沙坑”。

2c 西蒙