Хранимая процедура с множественным выбором - взаимодействие с клиентским инструментом?

Question

Предположим, у меня есть хранимая процедура следующим образом:

create procedure p_x
as
begin
   select 'a','b','c'
   select 'c','d','e'
   select 'e','f','g'
end
go

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

I 'Я ищу лучшую производительность и лучшие практики для ее решения.

1. Как отреагирует клиентский инструмент (например, Informatica Data Quality), вызывающий эту процедуру?

   • Будет ли получено 3 отдельных результата, только последний результат запроса или все результаты сразу?
   • Будет ли каждый отдельный запрос отправляться непосредственно клиенту (и будет ли процедура остановлена ​​до завершения)?или это делается после завершения процедуры?
   • Это хорошая практика, чтобы работать таким образом?Я искал обмен параметром табличного типа OUTPUT, но это не представляется возможным, если я прав (основываясь на других историях) (просто как входные данные)
   • Есть ли влияние на производительность таким образом?И если да, то как это сделать максимально эффективно (например, просто отправить один результат обратно клиенту)

Answer 1

Вам будет лучше, если вы отправите свой вопрос на форумах Informatica. Они должны быть в состоянии ответить на ваши вопросы точно и точно. Но я попробую.

Как отреагирует инструмент? Не знаю, но часто инструменты, которые поддерживают использование хранимых процедур в качестве источника данных, предполагают и используют один (и первый) набор результатов. Любые другие будут игнорироваться. Иди спроси в их форумах.

Получит ли он 3 ...? Примерно тот же вопрос и ответ, что и первый.

Будет ли каждый отдельный запрос ...? Ваша процедура выдает три набора результатов. Опять же, как клиент их потребляет, вы должны спросить на их форумах. Сама процедура не будет «останавливаться», ожидая, что клиент что-то сделает.

Это хорошая практика ...? Не по моему мнению. Кроме того, публикация полной бессмысленной процедуры не является полезным инструментом для обсуждения плюсов и минусов этого подхода. Может ли это быть полезным? Скорее всего. Но это не часто делается IME. Кроме того, вы имеете дело с инструментом, с которым вы не знакомы. Чем проще вы держите вещи, тем лучше вы в конечном итоге, независимо от ваших инструментов.

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

Есть ли влияние на производительность ...? На это не может быть ответа. Производительность всегда, ВСЕГДА специфична для конкретной ситуации (запрос, схема и т. Д.). Основываясь на этом последнем предложении, я думаю, что вы не внесли коррективы в мышление с точки зрения множеств - что является критически важным для написания эффективного SQL. Скорее, я предполагаю, что вы думаете с точки зрения цикла, который включает в себя оператор выбора, и каждая итерация будет производить набор (возможно, 1, но кто знает) строк. Если вы думаете, что у вас есть «опция» для создания только одного набора результатов из 3 строк против 3 наборов результатов из 1 строки, то вы, скорее всего, застряли в RBAR земле. В любом случае, на это нельзя ответить. Это также вопрос для людей Informatica.