Новое в PL / SQL - возвращение вопроса о множественных результирующих наборах

Question

Хорошо - у меня достаточно обширный опыт работы с SQL Server, но раньше я только осматривался в Oracle.Ну, толчок пришелся на пуш, и мне нужно создать относительно сложный запрос.По сути, это сводится к следующему в T-SQL:

SELECT Col1 
INTO #tmpTable
FROM Table1
WHERE Col3 = @paramValue

SELECT Col1
FROM #tmpTable

SELECT OtherCol
FROM Table2
INNER JOIN #tmpTable 
  ON Table1.Col1 = Table2.fkCol1

Причина этой последовательности заключается в том, что первоначальный вызов Table1 является чрезвычайно тяжелым (время выполнения ~ 5 с), потому что это очень сложный вызов для нашегохранилище данных.Я хотел бы вернуть результаты из Таблицы 2 в отдельном вызове, поскольку в Таблице 2, вероятно, будет 5-10 записей для каждой из Таблицы1, и это облегчает поворот моего интерфейса.

Я в курсечто я могу сделать

SELECT Table1.Col1, Table2.OtherCol
FROM Table1
LEFT JOIN Table2 
  ON Table1.Col1 = Table2.fkCol1

и затем повторно нормализовать данные в интерфейсе (обрабатывая только первую запись для Col1, затем все записи OtherCol, пока я не обнаружу новый Col1)

Я не эксперт по БД, поэтому я не уверен, какой подход лучше.С одной стороны, первое решение проще для меня.Это также (ощущение инстинкта) выглядит более производительным, так как не нужно будет возвращать «толстые» результаты Таблицы1, связанной с Таблицей2.Table1 будет возвращать ~ 1200 строк и шириной ~ 2 КБ.Таблица 2 значительно меньше (шириной ~ 20 байт), но содержит больше строк (6000-12000).

Итак, в конечном счете, мой вопрос заключается в том, какое решение лучше для среды PL / SQL, и если этоВо-первых, как лучше всего это сделать?Глобальная временная таблица / курсор / дополнительный выбор / что?

Answer 1

Я бы использовал соединение. Его проще кодировать и читать, и он должен выполняться быстрее, чем три отдельных выбора. И если вы просто выберете Col1, не имеет значения, насколько «толстым» будет полный ряд.

Answer 2

Если вы беспокоитесь о производительности, вам просто нужно протестировать ее и сравнить результаты.Я лично пошел бы с решением соединения.Oracle сделает свое дело негласно и, вероятно, улучшит вашу производительность.

Вам также следует проверить Планы выполнения для запросов.Я уверен, что ваша среда разработки позволяет вам быстро увидеть план выполнения.Стоимость ваших запросов даст вам хорошее представление о том, что происходит, и поможет вам принять решение.

Answer 3

В ответ на ваш комментарий о незнании, как реализовать первое решение:

procedure get_data(p_paramValue in varchar2, 
                  c_data1 out sys_refcursor,
                  c_data2 out sys_refcursor)
is
  v_tmptable in varchar2(30);
begin
  SELECT Col1 INTO v_tmpTable
  FROM Table1
  WHERE Col3 = p_paramValue;

  open c_data1 for 'SELECT Col1 FROM '||v_temptable;

  open c_data2 for
    'SELECT OtherCol FROM Table2 INNER JOIN '||v_tmpTable|| 
    ' ON Table1.Col1 = Table2.fkCol1'; 
end get_data;

Предполагается, что данные в Table1.Col1 являются доверенными, поскольку в обоих курсорах существует уязвимость для внедрения.