Otimizando Stored Procedures #6
Conversation
| GO | ||
| ``` | ||
|
|
||
| >O uso do filtro *WHERE* 1 = 1, é apenas um facilitador para a escrita dos demais filtros da consulta. Dessa forma não se faz necessário ficar testando se algum filtro já foi adicionado anteriormente a consulta. Na hora de avaliar os predicados da consulta o compilador ignora esse filtro ao montar o plano de execução. |
There was a problem hiding this comment.
caso eu não use ele, teria que ficar testando se eu já concatenei a cláusula WHERE antes de escrever os outros ANDs.
algo assim:
'
INNER JOIN Person.CountryRegion as E ON D.CountryRegionCode = E.CountryRegionCode ') +
IIF (@BusinessEntityID IS NULL, '', '
WHERE A.BusinessEntityID = @BusinessEntityID ') +
IIF (@StateProvinceID IS NULL, '', IIF(@BusinessEntityID IS NULL, 'WHERE ', 'AND ') + '
C.StateProvinceID = @StateProvinceID ') +
IIF (@CountryRegionCode IS NULL, '', IIF(@BusinessEntityID IS NULL OR @StateProvinceID IS NULL, 'WHERE ', 'AND ') + '
D.CountryRegionCode = @CountryRegionCode ')
O que de certa forma deixa menos legível o código.
Então eu opto por usar um where sem sentido (1 = 1), para uma escrita mais clean.
|
|
||
|  | ||
|
|
||
| Existe, porém, uma desvantagem ao utilizar essa abordagem de *dynamic queries*. Eventualmente poderão ser criados muitos planos de execução para essa mesma *stored procedure* que serão armazenados no cache de planos. Entretanto o ganho de performance com essa solução irá mais que compensar por isso. |
There was a problem hiding this comment.
Qual o tamanho disso? Muitos, quanto?
There was a problem hiding this comment.
Depende da quantidade de parâmetros diferentes que tua stored procedure aceita.
No exemplo duas chamadas com parâmetros diferentes, geraram dois planos.
Cada plano diferente vai ir para o cache. Antes da implementação, apenas um plano seria criado para a stored procedure, independente dos parâmetros passados (origem do problema).
|
|
||
| **Há algum tempo, por ingenuidade, alguns programadores assumem que usar *stored procedures* é uma coisa ruim. Muitos assumem que há risco de “vazar” o domínio do código aplicação para o banco de dados. Entretanto, quando isso ocorre, a causa é o abuso da tecnologia e não da tecnologia em si.** | ||
|
|
||
| Utilizar *stored procedures* para consultar o banco de dados tem uma série de benefícios comparado com consultas *ad hoc*: são mais rápidas, reduzem o tráfego na rede, são mais seguras e podem encapsular código reutilizável. Além de tudo isso, são armazenadas já pré-compiladas pelo *SQL Server*. |
There was a problem hiding this comment.
Teríamos que indicar, de alguma forma, o que vamos mostrar no post. Não há indícios do que iremos fazer e a solução que iremos propor
There was a problem hiding this comment.
Vou tentar pensar em uma introdução melhor. Embora não queria já entrar direto no problema, sem essa introdução prévia.
There was a problem hiding this comment.
Tem o Fato e o Insight que dão uma pincelada no problema, no final do artigo. Mas não queria me tornar repetitivo, escrevendo algo semelhante também na introdução.
There was a problem hiding this comment.
Incluí mais uma frase na introdução do post, explicando sobre o conteúdo dele.
|
Michelon, senti falta de um parágrafo de conclusão com uma call to action no final. |
Otimizando Stored Procedures