none
"Preço" de uma SP na performance de um Banco de dados. RRS feed

  • Pergunta

  • Pessoal, boa tarde. Esse é meu primeiro Post. Antes de mais nada, um breve histórico.

    Sou desenvolvedor Java desde 2004 e desde 2011 tenho feito trabalhos com SQL Server (primeiramente o 2005 e agora o 2008 R2). Porém esses trabalhos foram sempre o mais simples possível, eu não sei configurar o SQL Server, não sei "tunnar", etc. Malmente sei funções de SQL e construir SPs básicas para salvar-me no dia a dia.

    Aqui na empresa, quando a equipe cresceu, apareceram novos profissionais e entre eles, os de SQL. Já conversei com outras pessoas sobre isso, mas gostaria de vir ao fórum especializado pra tirar essa dúvida:

    Há algum custo de se encher o Banco de dados de SPs, mesmo que as mais simples? Preciso me preocupar com ele, ou não há um limite no horizonte e posso abusar de SPs a vontade?

    A pergunta surgiu pois nos últimos dias, até pequenas consultas estão indo para dentro de SPs pelo simples fato de não precisar parar o servidor e App para atualizações de consultas.

    Posso estar me preocupando a toa, mas realmente surgiu-me essa dúvida em relação a como fica a performance e demais requisitos do SQL com o "abuso" de SPs.

    Agradeço desde já a atenção dispensada.

    Att.  

    terça-feira, 3 de junho de 2014 19:10

Respostas

  • Adriano,

    Tudo vai depender do consumo de dados. As procedures estão disponíveis dentro do SQL Server e vão consumir recursos de processamento proporcionalmente como serão utilizados e como foram escritos.

    Seria como os componentes ou executáveis disponíveis em um sistema operacional, conforme aumenta o uso de vários simultaneamente, mais recursos de hardware são consumidos.

    Criar procedures e views são uma Boa Prática para evitar à recompilação de uma ou mais aplicações, além de ser mais rápida em processos de manutenção. Porém trabalhar em um ambiente com camadas bem definidas poderá ajudar a manter seus Apps com uma boa performance.

    Apenas seria interessante analisar o T-SQL que precisa estar em procedures e o que pode ser views.

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"
    terça-feira, 10 de junho de 2014 19:01

Todas as Respostas

  • Deleted
    sexta-feira, 6 de junho de 2014 21:49
  • Adriano,

    Tudo vai depender do consumo de dados. As procedures estão disponíveis dentro do SQL Server e vão consumir recursos de processamento proporcionalmente como serão utilizados e como foram escritos.

    Seria como os componentes ou executáveis disponíveis em um sistema operacional, conforme aumenta o uso de vários simultaneamente, mais recursos de hardware são consumidos.

    Criar procedures e views são uma Boa Prática para evitar à recompilação de uma ou mais aplicações, além de ser mais rápida em processos de manutenção. Porém trabalhar em um ambiente com camadas bem definidas poderá ajudar a manter seus Apps com uma boa performance.

    Apenas seria interessante analisar o T-SQL que precisa estar em procedures e o que pode ser views.

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"
    terça-feira, 10 de junho de 2014 19:01
  • Adriano,

    Eu particularmente gosto muito de utilizar Stored Procedure, acredito que é um dos melhores recursos que o SQL Server oferece, mas sou contra a ficar criando Stored Procedures por exemplo para realizar Insert, Update ou Delete, estes comandos já existem no SQL Server, não vejo o porque fazer isso.

    Normalmente eu cria algumas Stored Procedure para processos que necessitam ser processados diretamente no Servidor a fim de ganhar com a performance e integração direta ao SQL Server.

    O uso de Stored Procedure é sim uma ótima prática como o Durval citou, mas uma Stored Procedure mal elaboradora, sem qualquer tipo de análise ou teste pode sim ser um recurso ruim.

    Não existe nenhum tipo de limite de quantidade de Stored Procedure, quantidade de linhas ou funcionalidades que podem ser aplicadas a uma Stored Procedure, muito pelo contrário de todos os recursos programáveis no SQL Server, as SPs são as que possuem maior compatibilidade e flexibilidade.

    Veja as Stored Procedures como um camada(área ou faixa) que você esta criando em seu centralizando partes da sua aplicação que podem ser consideradas com componentes, deixando estes recursos do lado externo da aplicação, o que poderá facilitar em muito a sua manutenção.

    Mas sempre digo aos meus alunos, tudo em excesso pode ser perigoso e sempre temos que analisar a necessidade para entender do que precisamos.

    Então ter ou não ter muitas SPs em seu ambiente vai depender de você e sua equipe.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    quarta-feira, 11 de junho de 2014 18:50
    Moderador