Инкрементный механизм запросов для Oracle / RDBMS - PullRequest
1 голос
/ 26 сентября 2019

Я не уверен, правильное ли слово "incremental" для этого или нет.Я продолжу формулировать проблему.

У меня есть две большие таблицы, X и Y. Z - еще одна таблица, которая является объединением X и Y.

Create Table Z as 
select X.col1, X.col2, Y.col2, Y.col3 
from X 
join Y on X.id=Y.id"

Теперь, когда бы нилюбое значение обновляется в таблице X или Y, мои данные в Z должны быть обновлены.Есть два способа сделать это:

  1. Обновлять таблицу Z явным образом через регулярные промежутки времени.Минусы: 1) данные не обновляются в режиме реального времени; 2) обновление, которое снова запускает соединение, заняло много времени, хотя изменилось только поле.

  2. Инкрементные обновления в таблице Z в соответствии с любыми изменениями в X и Y. Возможное преимущество заключается в том, что оно выполняется в режиме реального времени и не займет много времени для обновления только для соответствующих строкбудет обновлено.

Я ищу любую помощь / направление о том, как реализовать 2) подход для Oracle или любой другой базы данных?

1 Ответ

3 голосов
/ 26 сентября 2019

Чтобы превратить комментарии (и подразумеваемые ответы) Джастина и Алекса в ответ, вы, вероятно, захотите использовать материализованное представление.Если вы не знакомы с ними, когда данные в обычном представлении физически не существуют, а просто возвращаются из данных в таблицах в определении представления, материализованное представление создает физическое представление данных, и это материализованное представление можетобновляться различными способами.Я буду ссылаться на объединение между таблицей X и таблицей Y («базовые таблицы») как таблицей Z ниже, но Z может быть таблицей, представлением или материализованным представлением:

Как уже упоминал Алекс, могут быть причины, по которым вы, возможно, не захотите использовать материализованное представление, поэтому позвольте мне упомянуть некоторые распространенные причины , а не :

  • Полученное материализованное представление будетзанимают большое количество физического дискового пространства;например, при объединении огромных таблиц X и Y создастся огромная таблица Z
  • Базовые таблицы X и Y часто обновляются, и к таблице Z обращаются не так часто, какобновлены базовые таблицы

Опять же, приведенные выше опрометчивые обобщения;вам нужно протестировать различные варианты.

Преимущества материализованного представления вместо реальной таблицы Z или представления Z включают:

  • Быстрый доступ к даннымпо сравнению с представлением, извлекающим данные из базовых таблиц
  • Материализованное представление может обновляться по расписанию на основе времени или при изменении данных в базовых таблицах или по запросу.Поскольку вы включили тег , вы можете обновить материализованное представление после выполнения определенной процедуры или задания.
  • Вы можете создавать журналы материализованного представления в базовых таблицах, чтобы ускорить обновление материализованного представления дажеподробнее.
  • Если запросы к таблице Z частые, материализованное представление будет , вероятно, быстрее, чем обычное представление.

Итак, протестируйте несколько способов:ваши первые два пути, и регулярное представление, и материализованное представление.Если таблице Z не нужно много столбцов из базовой таблицы, может работать обычное представление.Если критерии объединения дают небольшое количество строк, материализованное представление может быть лучшим.

Ссылки:

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...