Supondo que eu tenha o seguinte procedimento
CREATE PROCEDURE foo (table1_id IN TABLE1.table1_id%type,
table1_val IN TABLE1.table1_value%type)
AS
SQL_UPDATE VARCHAR2(500) := 'UPDATE TABLE1 SET table1_value =:1 WHERE table1_id = :2';
BEGIN
--.....
--1 :
EXECUTE IMMEDIATE SQL_UPDATE USING foo.table1_val, foo.table1_id;
--2 :
UPDATE TABLE1 SET table1_value = foo.table1_val WHERE table1_id = foo.table1_id;
END;
Além do estilo/legibilidade, há alguma penalidade de desempenho para usar a consulta dinâmica (1) em comparação com (2) nesses casos (quero dizer, quando é absolutamente evitável)?
Obrigada.
A única razão pela qual eu poderia fazer isso é se eu precisasse endereçar um objeto que pode não existir no tempo de compilação - por exemplo, se eu tivesse código para criar novas tabelas externas conforme necessário.
Como isso implica, a instrução SQL dinâmica não é analisada quando o PL/SQL compila, então você não tem ideia se está correto ou não, e as dependências não são armazenadas no banco de dados.
Para instruções SQL simples, como a que você está descrevendo, há de fato um impacto geral no desempenho de um banco de dados Oracle. Como o SGBD deve fazer soft parsing do sql toda vez (o que também toma um pouco de tempo), ele precisa gravar no SGA e pode acabar tirando recursos de planos de execução já analisados de consultas estáticas, já que o SGA não é infinito. Se estiver executando muitas instruções em SQL dinâmico dentro de procedimentos, você experimentará uma deterioração do desempenho com o tempo. Lembre-se de que detectar erros causados por SQL dinâmico é muito mais complicado do que erros gerados por instruções SQL padrão.
Eu recomendaria apenas recorrer ao SQL dinâmico se você estiver fazendo um trabalho administrativo complexo com objetos de banco de dados ou se sua consulta diferir muito com a entrada dos procedimentos. Mesmo nesses casos, você ficaria melhor com declarações if/else ditando suas consultas.