Recorrentes consultas SQL

Question

O que é considerado a melhor prática para a execução de consultas SQL recorrentes? O meu entendimento é usar uma consulta parametrizada e transformá-lo em uma declaração preparada após a primeira execução. E se essa consulta precisa ser executado por vários segmentos? Será que eu preciso para criar uma declaração preparada para cada tipo de consulta para cada segmento? Ou é a análise de instruções SQL tão eficiente hoje em dia que as declarações preparadas não são mais necessárias?

Answer 1

Boa pergunta -. Respondeu um pouco de cada vez

• O que é considerado a melhor prática para a execução de consultas SQL recorrentes?

Se a consulta será repetido para além de diferenças nos parâmetros, em seguida, usar declarações preparadas.

• O meu entendimento é usar uma consulta parametrizada e transformá-lo em uma declaração preparada após a primeira execução.

Essa é a minha opinião sobre o que deve ser feito. Classicamente, o conselho era preparar todas as consultas quando o programa começou. Em minha opinião, este foi sempre um disparate; que sobrecarrega o servidor com consultas, muitos dos quais não serão utilizados em um determinado prazo, desperdiçando memória no cliente e DBMS. Era sempre mais sensata para preparar declarações sobre a demanda; quando foi necessário em primeiro lugar, e não menos que fosse necessário. Eu permitir que uma exceção para as demonstrações que 'sempre' ser executadas -. Mas eu teria que ser convencidos de que 'sempre' foi muito próximo a 100% do tempo

• E se essa consulta precisa ser executado por vários segmentos? Será que eu preciso para criar uma declaração preparada para cada tipo de consulta para cada segmento?

Isso depende de como os diferentes tópicos comunicar com os DBMS. Nos SGBD com o qual estou familiarizado, se houver uma única conexão que os fios todos compartilham, então você só precisa prepará-lo uma vez para a única conexão. Se cada thread tem sua própria conexão separada, então você precisa para preparar a declaração para cada segmento separadamente.

• Ou é a análise de instruções SQL tão eficiente hoje em dia que as declarações preparadas não são mais necessárias?

Machines são rápidos - sim. E para as demonstrações não repetidos, não vale a pena se preocupar com a sobrecarga. Mas se você estiver indo para executar a consulta de alguns milhões de vezes, então o custo de prepará-lo alguns milhões de vezes começa a somar. Além disso, máquinas de servidor de banco de dados são recursos geralmente compartilhada, mas a declaração é susceptível de ser preparada separadamente para cada usuário, por isso, se você tiver vários usuários martelando o sistema com consultas repetidas que são descartados, o servidor vai estar muito ocupado preparando consultas para executar qualquer deles rápido.

Assim, a minha resposta é "Não". instruções preparadas ainda são benéficos quando as consultas serão repetidas com freqüência suficiente - onde 'muitas vezes' provavelmente não é tudo o que muitas vezes. Centenas de vezes - usar declarações preparadas. Dezenas de vezes - provavelmente usar declarações preparadas. Menos do que isso -. Talvez não usar declarações preparadas

Answer 2

Bem, você não mencionou o ambiente que você está usando, mas em geral, você também pode considerar procedimentos armazenados (se o seu motor suportes DB-lo). Tem a vantagem de construir uma camada de abstração adicional no próprio banco de dados, tornando o esquema de banco de dados exata menos relevante para aplicações cliente.

Usando consultas parametrizadas é incentivada a maior parte do tempo, não só por uma questão de performance, mas para a segurança contra problemas de conversão de tipo de dados de injeção e prevenir SQL (localizada data e hora).