Лучший способ инкапсулировать сложную логику курсора Oracle PL / SQL в виде представления?

Вместо того, чтобы иметь входной параметр в качестве курсора, у меня была бы табличная переменная (не знаю, есть ли у Oracle такая вещь, я - парень TSQL) или заполнить другую временную таблицу значениями идентификатора и присоединиться к ней в представлении / function или где угодно.

Единственное время для курсоров, по моему честному мнению, - это когда вы имеют зацикливаете. И когда вам нужно зацикливаться, я всегда рекомендую делать это вне базы данных в логике приложения.

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

Разработчики Oracle, похоже, используют курсоры гораздо охотнее, чем я мог подумать. Это тем более удивительно, учитывая природу PL / SQL рабства и дисциплины.

Самое простое решение:

1. Создайте глобальная временная таблица, содержащий только нужные вам идентификаторы:

   CREATE GLOBAL TEMPORARY TABLE tab_ids (id INTEGER)  
   ON COMMIT DELETE ROWS;
   

2. Заполните временную таблицу нужными вам идентификаторами.

3. Используйте операцию EXISTS в своей процедуре, чтобы выбрать строки, которые есть только в таблице идентификаторов:

     SELECT yt.col1, yt.col2 FROM your\_table yt  
      WHERE EXISTS (  
         SELECT 'X' FROM tab_ids ti  
          WHERE ti.id = yt.id  
      )
   

Вы также можете передать строку идентификаторов, разделенных запятыми, в качестве параметра функции и преобразовать ее в таблицу. Это выполняется одним SELECT. Хотите узнать больше - спросите как :-) Но это должен быть отдельный вопрос.

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

Не зная ни требований, ни сложности того, чего вы хотите достичь. Я бы попытался

1. чтобы определить представление, содержащее (возможно, сложную) логику в SQL, иначе я бы добавил немного PL / SQL в смесь с;
2. Конвейерная табличная функция, но использующая тип коллекции SQL (вместо временной таблицы). Вот простой пример: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4447489221109

Номер 2 даст вам меньше движущихся частей и решит проблему согласованности.

Мэтью Батлер

Я думаю, что способ подойти к этому - использовать аналитические функции ...

Я настроил ваш тестовый пример, используя:

create table employee_job (
    emp_id integer,
    job_id integer,
    status varchar2(1 char),
    eff_date date
    );  

insert into employee_job values (1,10,'A',to_date('10-JAN-2008','DD-MON-YYYY'));
insert into employee_job values (2,11,'A',to_date('13-JAN-2008','DD-MON-YYYY'));
insert into employee_job values (1,12,'A',to_date('20-JAN-2008','DD-MON-YYYY'));
insert into employee_job values (2,11,'T',to_date('01-FEB-2008','DD-MON-YYYY'));
insert into employee_job values (1,10,'T',to_date('02-FEB-2008','DD-MON-YYYY'));
insert into employee_job values (2,11,'A',to_date('20-FEB-2008','DD-MON-YYYY'));

commit;

Я использовал функцию вести, чтобы получить следующую дату, а затем обернул все это как подзапрос, чтобы получить записи «A» и добавить дату окончания, если она есть.

select
    emp_id,
    job_id,
    eff_date start_date,
    decode(next_status,'T',next_eff_date,null) end_date
from
    (
    select
        emp_id,
        job_id,
        eff_date,
        status,
        lead(eff_date,1,null) over (partition by emp_id, job_id order by eff_date, status) next_eff_date,
        lead(status,1,null) over (partition by emp_id, job_id order by eff_date, status) next_status
    from
        employee_job
    )
where
    status = 'A'
order by
    start_date,
    emp_id,
    job_id

Я уверен, что есть некоторые варианты использования, которые я пропустил, но вы поняли идею. Аналитические функции - ваш друг :)

EMP_ID   JOB_ID     START_DATE     END_DATE            
  1        10       10-JAN-2008    02-FEB-2008         
  2        11       13-JAN-2008    01-FEB-2008         
  2        11       20-FEB-2008                              
  1        12       20-JAN-2008                              

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

Не могли бы вы сделать это:

• Создайте постоянный стол с лучшей структурой
• Заполните его, чтобы он соответствовал данным в первой таблице
• Определите триггер базы данных для исходной таблицы, чтобы с этого момента новая таблица синхронизировалась

Затем вы можете просто выбрать из новой таблицы для составления отчета.