Seu código de exemplo é tão simples que haverá pouca diferença, mas nesse caso a versão estática provavelmente executaria melhor.
A principal razão para usar SQL dinâmico para desempenho é quando a instrução SQL pode variar de maneira significativa - ou seja, você pode adicionar código extra à cláusula WHERE em tempo de execução com base no estado do sistema (restringir por uma subconsulta em Endereço, se Endereço inserido, etc).
Outra razão é que, às vezes, usar variáveis Bind como parâmetros pode ser contraproducente.
Um exemplo é se você tiver algo como um campo de status, onde os dados não são distribuídos uniformemente (mas são indexados).
Considere as 3 afirmações a seguir, quando 95% dos dados são 'Processados'
SELECT col FROM table
WHERE status = 'U'-- unprocessed
AND company = :company
SELECT col FROM table
WHERE status = 'P' -- processed
AND company = :company
SELECT col FROM table
WHERE status = :status
AND company = :company
Na versão final, a Oracle escolherá um plano de explicação genérico. Na primeira versão, ele pode decidir que o melhor plano é começar com o índice no status (sabendo que as entradas 'Não' processadas são uma parte muito pequena do total).
Você pode implementar isso através de diferentes instruções estáticas, mas onde você tem instruções mais complexas que mudam apenas alguns caracteres, o SQL dinâmico pode ser uma opção melhor.
Desvantagens
Cada repetição da mesma instrução SQL dinâmica incorre em uma análise suave, que é uma pequena sobrecarga comparada a uma instrução estática, mas ainda é uma sobrecarga.
Cada NOVA instrução sql (dinâmica ou estática) também incorre em um bloqueio na SGA (memória compartilhada) e pode resultar no envio de instruções 'antigas'.
Um design de sistema ruim, mas comum, é alguém usar SQL dinâmico para gerar seleções simples que variam apenas por chave - ou seja,
SELECT col FROM table WHERE id = 5
SELECT col FROM table WHERE id = 20
SELECT col FROM table WHERE id = 7
As instruções individuais serão rápidas, mas o desempenho geral do sistema se deteriorará, pois está matando os recursos compartilhados.
Além disso - é muito mais difícil interceptar erros em tempo de compilação com SQL dinâmico. Se estiver usando PL/SQL, isso está jogando fora uma boa verificação de tempo de compilação. Mesmo ao usar algo como JDBC (onde você move todo o código do banco de dados em strings - boa ideia!), você pode obter pré-parsers para validar o conteúdo do JDBC. SQL dinâmico =somente teste de tempo de execução.
Despesas gerais
A sobrecarga da execução imediata é pequena - está na milésima de segundo - no entanto, pode aumentar se estiver dentro de um loop / em um método chamado uma vez por objeto / etc. SQL com SQL estático gerado. No entanto, isso complicou o código e só foi feito porque precisávamos de velocidade.
