时间戳

首页 > 解决方案 > Maximo 的出站集成：物化视图不是合适的选择是否有原因？

oracle - Maximo 的出站集成：物化视图不是合适的选择是否有原因？

问题描述

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

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

标准集成选项似乎是：

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

我注意到物化视图通常不被认为是一个有效的集成选项。

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

据我所知，物化视图将是一种相当强大的集成技术。但是，我从未听说过我的任何同行将物化视图用于 Maximo 集成目的。

物化视图不是 Maximo 集成的合适选择是否有技术原因？

例子：

为了实现物化视图，两个数据库都需要是后期模型的 Oracle 数据库，但情况并非总是如此。

标签： oracleintegrationmaterialized-viewsmaximo

解决方案

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

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

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

其次（2），要使 MV（或视图）成功，它必须正确访问底层数据，这需要对正在访问的数据有全面的了解。可以使用 MV 和各种技术访问此处建议的数据类型，但这可能不是最好的方法（见下面的 3）。

第三（3），专有系统中的数据库表是事务性和面向过程的数据的动态环境的一部分。因此，确保上述 2 中的 MV 正确性的需要也适用于此。

第四（4），很可能是无知。我遇到了多少 Oracle 专业人士，他们参加过培训他们关于 MV 的课程？可能很少（我可以自己在这个群体中）。鉴于我刚刚承认的，为什么我认为我可以写这个回复？我想这是因为我的整个职业生涯都在使用 Oracle 和其他数据库。我曾经遇到过必须构建事务-> 数据仓库类型的解决方案的情况，这需要大量且持续的 MV 知识获取（广泛用于 Oracle 到 Oracle 的复制）。

第五 (5) 扩展 4 是观察到人们被他们最了解的工具所束缚。如果那是桌面或网络 GIS，那么这就是他们所知道的。在生产环境中对数据库的访问确实受到限制，因此除非存在完整的堆栈开发/测试/生产数据库，否则无法访问那种用于学习的“沙坑”。

2c西蒙

推荐阅读