2017-02-20 29 views
2

У меня есть представление о таблице. Оказывается, таблица перемещается, и обновленная версия ее создается каждую ночь. Это гарантирует, что всегда есть таблица ожидаемого имени, присутствующего в базе данных, но я не могу найти способ заставить мое представление продолжать указывать на текущую версию таблицы. Какая бы таблица не существовала при создании представления, это тот, который я в конечном итоге указываю даже после того, как он движется и становится устаревшим.Заданное имя таблицы Разрешение в представлении

ViewA:

select a, b, c from todays_table; 

todays_table остается тока в течение всего дня, а ночью он получает переименован в todays_table01. Теперь A теперь указывает на todays_table01 и появляется новая таблица под названием todays_table. Опять же, todays_table является текущим, но ViewA больше не является.

Есть ли способ отсрочить разрешение имени таблицы до тех пор, пока не будет использован вид? Я не смог получить EXECUTE IMMEDIATE, работая для заявления SELECT. Я думаю, что я мог бы получить динамический оператор SQL, если бы я использовал курсор, но я никогда не нуждался в них раньше, и я не уверен, что они правильный путь. Я читал около AUTO_REVAL, но я считаю, что это только задерживает разрешение до тех пор, пока в первый раз не будет использоваться вид и все еще будет зависеть в ту ночь.

Я мог бы, конечно, прекратить использование представления и просто переместить сложный запрос в мою программу, но есть много мест, в которых это необходимо, поэтому я хотел бы устранить все другие решения, прежде чем возвращаться к этому.

Было бы идеально, чтобы исключить временную таблицу и просто получить основную таблицу в течение дня, но это выходит за рамки моего понимания, поскольку я ничего не знаю о RPG II и OCL.

Спасибо за чтение.

Редактировать Per @Mr. По предложению Лламы я экспериментировал с использованием синонимов и псевдонимов, чтобы указать на todays_table, а затем, имея мой взгляд на синоним. К сожалению, в этом случае представление использует псевдоним, чтобы разрешить фактическое имя таблицы при создании, поэтому представление продолжает указывать на todays_table, когда оно переименовано в todays_table01, хотя псевдоним продолжает ссылаться на todays_table.

Edit 2 Я принимая ответ @ mustaccio, потому что он работает и будет разумный подход к этой проблеме, если бы я мог получить параметры туда, куда им нужно. Мой конкретный проект требует гибкости, поэтому я на самом деле собираюсь прыгнуть на ночную прогулку по технологиям и добавить программу, чтобы воссоздать мои взгляды после того, как процесс перепутался со своими рекомендациями, как предлагал @ danny117.

Спасибо всем, кто ответил, я много узнал о том, как все эти части работают вместе.

+1

Звучит как работа для синонима. Сделайте точку обзора синонимом, затем обновите синоним, чтобы указать на текущую «активную» таблицу. –

+1

Входите в процесс, который создает новую ежедневную таблицу и создает там вид. – danny117

+1

Создайте и замените представление перед каждым использованием. – danny117

ответ

2

Я думаю, вы могли бы добиться того, что вы хотите, обернув свое определение вида в функции SQL таблицы, что-то вроде

CREATE FUNCTION insteadofview (<parameters>) 
RETURNS TABLE (<columns>) 
... 
RETURN 
    SELECT <the rest of your view definition> 

В зависимости от того, как вы запрашиваете ваш взгляд, вам, вероятно, нужно пройти поиск критерии в функции как параметры, в противном случае производительность будет субоптимальной, так как функция должна будет возвращать все строки из запроса до того, как будут применены аргументы поиска.

According to the manual, как вы заметили взгляды на таблицу, которая переименована, продолжает указывать на исходную таблицу объект. Однако процедуры, включая функции таблицы, будут признаны недействительными, и их планы будут снова подготовлены при следующем вызове, используя исходную исходную таблицу имя.

У меня нет возможности проверить это.

Full syntax to create a table function.

+1

Благодарим вас за ответ. Это работает! Я даже могу взглянуть на UDTF, поэтому пользователю не нужно беспокоиться о деталях. Недостатком, как вы упомянули, является производительность. Когда я изменяю представление как оболочку, указывающую на UDTF, мой запрос занимает около 14 секунд. Когда UDTF не задействован, тот же запрос занимает первые 5 секунд, затем 2.9 при последующих запусках, когда оптимизатор запросов запускается. Оптимизатор запросов, похоже, не знает, что делать с UDTF (понятно). Я уверен, производительность была бы лучше, если бы я добавил параметры в UDTF, как было предложено. –