Ouvi dizer que você não deseja usar o SQL dinâmico. Você pode dar um exemplo concreto ou exemplo da vida real? Pessoalmente, codifico algumas vezes no meu banco de dados. Eu acho que está tudo bem, porque é flexibilidade. Meu palpite é sobre injeção ou desempenho de SQL. Algo mais?
Respostas:
Não há nada de errado em usar o SQL dinâmico, se necessário. De fato, em algumas circunstâncias, é a única opção que você tem. É mais uma recomendação não usá-lo, pois isso pode levar a uma injeção de SQL se sua entrada não for higienizada, e sim, o uso de SQL dinâmico em módulos chamados frequentemente pode ser prejudicial ao desempenho.
Eu não acho que exista um exemplo concreto, mas eu diria o seguinte: tente alcançar o que você é depois de usar consultas e declarações regulares primeiro - somente depois que você tiver esgotado todas as outras vias, faça isso dinamicamente. Lembre-se de que a execução de uma string SQL dinâmica é feita em uma sessão de usuário separada para o módulo que a está chamando - para que você possa encontrar problemas de permissões nos quais não espera nenhum.
Se você está preocupado com o desempenho; teste-o. Se você está preocupado com segurança; valide sua entrada. Não há certo ou errado - apenas que você use seu melhor julgamento com base nas informações e ferramentas que você tem à sua disposição no momento.
SQL dinâmico é uma ferramenta. E, como ferramenta, possui algumas aplicações - para trabalhos administrativos é uma benção, por exemplo.
Não é tão bom no SP usado pelos aplicativos, especialmente se você não gerencia a parametrização do código gerado (as versões mais recentes do SQL Server reduzem os problemas, mas ainda são válidos).
Não vou entrar em detalhes aqui, por isso vou recomendar um excelente artigo sobre questões de SQL dinâmico: A maldição e as bênçãos do SQL dinâmico do MVP Erland Sommarskog.
É como a maioria dos recursos de dbms, se você usá-lo na situação certa, ele faz seu trabalho bem, na situação errada, ele faz mal.
Prós: Algumas coisas simplesmente não podem ser feitas sem ele. Normalmente, descobri que isso é apenas para trabalho administrativo, e não para o código do aplicativo. Alguns comandos do sistema não permitem que parâmetros sejam usados como entrada. Por exemplo, se eu precisar executar algo através de um sproc em todos os bancos de dados, em muitas instâncias com bancos de dados desconhecidos, e o comando não aceitar parâmetros, geralmente resolvo isso através do SQL dinâmico. No entanto, isso é mais importante no Sybase ASE do que no MSSQL.
Contras: não vou me interessar muito, pois acho que todos já sabemos, mas pode haver algum risco de injeção de SQL se usada incorretamente. O maior para mim é que a consulta será tratada como ela é, uma consulta adhoc exclusiva e não parte do plano de consulta compilado. Para algo que é executado ocasionalmente, não é grande coisa. Para algo que é executado centenas de vezes por minuto e que possui muitos sql exclusivos, isso geraria muitos planos de consulta novos, potencialmente desnecessários, que consumiam ciclos e diminuíam o tempo válido do cache do plano.
Não use o SQL dinâmico.
99% das vezes que o SQL dinâmico é usado devido à falta de conhecimento sobre como usar parâmetros opcionais em procedimentos armazenados, o restante 1% é usado para criar uma consulta altamente complexa para um relatório que o cliente não entende até. A maldição e as bênçãos do SQL dinâmico não mostram um exemplo de por que seria uma boa ideia usá-lo, mas apenas sugere que é problemático porque aumenta a complexidade da depuração, manutenção, sem mencionar os riscos de segurança do SQL Injeção, baixo desempenho, não porque o cache, mas as más práticas que o acompanham, como o uso de tabelas e cursores temporários, o que, naturalmente, é preguiçoso e ingênuoprogramador abusaria de. Não existe flexibilidade para escrever consultas dessa maneira, o SQL é uma linguagem declarativa e deve ser tratada como tal.
A preguiça é a raiz de todo mal.
Paradoxalmente, essa resposta está classificada entre as mais votadas .