Исходящие интеграции от Maximo: есть ли причина, по которой материализованные представления не являются подходящим выбором? - PullRequest
Новая
       42

Исходящие интеграции от Maximo: есть ли причина, по которой материализованные представления не являются подходящим выбором?

3 голосов
/ 23 декабря 2019

Я хочу настроить исходящую интеграцию из Maximo 7.6.1.1 во внешнюю систему. И Maximo, и внешняя система имеют базы данных Oracle 12c.

Во внешней системе я хочу выбрать открытые WO из таблицы Maximo WORKORDER для анализа данных почти в реальном времени.

Стандартные параметры интеграции:

  1. Плоский файл
  2. XML-файл
  3. Интерфейсная таблица
  4. Веб-служба

Я заметил, что материализованные представления обычно не считаются допустимым вариантом интеграции.

Например, я мог бы создать материализованное представление во внешнемсистема в таблице Maximo.WORKORDER через ссылку dblink. Материализованное представление может быть настроено несколькими различными способами, включая обновление по расписанию, почти в реальном времени и т. Д.

Насколько я могу судить, материализованное представление будет довольно надежной техникой интеграции. ,Однако я не слышал о том, чтобы кто-либо из моих пиров использовал материализованные представления для целей интеграции Maximo.

Существует ли техническая причина, по которой материализованные представления не подходят для интеграции Maximo?

Пример:

Обе базы данных должны быть базы данных Oracle поздней модели, чтобы материализованные представления были возможны, что не часто бывает

1 Ответ

3 голосов
/ 27 декабря 2019

Материализованные представления Oracle являются отличным инструментом для разработчика моделей данных и конструктора баз данных. Они, буквально, являются одной из лучших реализаций MV на рынке баз данных (мой основной опыт - с Oracle, и я работал с SQL Server и PostgreSQL: я не работал с DB2 или другими базами данных). В качестве созданного экземпляра они предоставляют всю мощь традиционных представлений, но с дополнительными функциональными возможностями для создания высокопроизводительных, ограниченных и проиндексированных «табличных» объектов. Я думаю, что можно представить MV как таблицу с метаданными, описывающими их конструкцию и обновление.

Почему MV не так широко используются?

Во-первых (1) в упомянутом случае доступа к Maximo всегда существует проблема доступа к схеме проприетарного продукта.

Во-вторых (2), чтобы MV (или представление) было успешным, он должен правильно обращаться к базовым данным, что требует полного понимания данных, к которым осуществляется доступ. Доступ к предлагаемым здесь типам данных может быть получен с использованием MV и различных техник, но это может быть не лучшим способом (см. Ниже 3).

В-третьих (3) таблицы базы данных в проприетарных системах являются частьюдинамическая среда транзакционных и процессно-ориентированных данных. Таким образом, необходимость обеспечения правильности MV в пункте 2 выше также применима и здесь.

Четвертый (4), очень вероятно, невежество. Сколько специалистов Oracle я встретил, которые были на курсах, чтобы рассказать им о MV? Вероятно, очень мало (я мог бы сам среди этой группы). Почему я думаю, что могу написать этот ответ, учитывая то, что я только что признал? Я думаю, это потому, что я работал с Oracle и другими базами данных всю свою профессиональную жизнь. У меня были ситуации, когда мне приходилось создавать решения типа транзакционного> хранилища данных, которые требовали большого и устойчивого приобретения знаний для MV (широко использовались для репликации Oracle в Oracle).

В-пятых (5) расширение 4 - этонаблюдение, что люди преданы инструменту, который они знают лучше всего. Если это настольная или веб-ГИС, то это то, что они знают. Доступ к базам данных в производственных средах, как правило, ограничен, поэтому своего рода «песочница» для обучения недоступна, если не существует полной базы данных dev / test / prod.

2c Simon

...