none
Quando não utilizar stored procedure? RRS feed

  • Pergunta


  • Olá pessoal.

    Estou com mais uma dúvida.
    Quando não devo utilizar stored procedure em uma aplicação?
    Pois em todos artigos que já li, sempre falam para utilizar stored procedure ao invés de utilizar comandos DML para acessar a base de dados direto. Sei que tem muitas vantagens, como segurança, mas devo utilizar em toda a aplicação? Não existe, um "se"?
    terça-feira, 11 de novembro de 2008 18:54

Respostas

  • Boa Tarde Marcelo,

     

    Sua pergunta é sem dúvida excelente, pois, tão importante quanto saber quando usar é saber quando não usar. Em todo caso ela também é igualmente muito difícil de responder já que Stored Procedure representam muitos benefícios e em tese (se devidamente utilizadas) não possuem restrições em relação a consultas Adhoc.

     

    O único cenário que vejo que Stored Procedures não devem ser usadas (e mesmo assim isso é totalmente contornável) é quando você deseja construir uma aplicação independente de banco de dados e deve montar o mesmo SELECT para funcionar em todos os bancos. Ainda assim, não acho que essa seja uma boa solução para uma aplicação independente do fornecedor de banco de dados.

     

    Outra solução ocorre quando você possui ferramentas CASE que geram as classes e já possuem todos os métodos CRUD (Create, Retrieve, Update & Delete) prontos. Nesse caso, a parte de acesso a dados já está praticamente codificada e montar tudo em SP é um atraso em relação ao tempo de desenvolvimento (embora proporcione vários benefícios posteriormente). Ainda assim, muitos geradores de classe já geram os métodos em SP.

     

    Sinceramente, tenho dificuldades em elencar cenários em que stored procedures não devam ser usadas. O que posso falar com facilidade é para que você evite colocar em SPs coisas que não são de banco de dados como por exemplo geração de arquivos, formatação de páginas HTML, envio de e-mails, etc. Tais funcionalidades definitivamente não devem ficar em SP. Toda vez que uma SP executa algo que não seja recuperar e gravar dados, ela estará tornando o banco de dados mais lento para a recuperação e gravação de dados.

     

    [ ]s,

     

    Gustavo

    terça-feira, 11 de novembro de 2008 19:51

Todas as Respostas

  • Boa Tarde Marcelo,

     

    Sua pergunta é sem dúvida excelente, pois, tão importante quanto saber quando usar é saber quando não usar. Em todo caso ela também é igualmente muito difícil de responder já que Stored Procedure representam muitos benefícios e em tese (se devidamente utilizadas) não possuem restrições em relação a consultas Adhoc.

     

    O único cenário que vejo que Stored Procedures não devem ser usadas (e mesmo assim isso é totalmente contornável) é quando você deseja construir uma aplicação independente de banco de dados e deve montar o mesmo SELECT para funcionar em todos os bancos. Ainda assim, não acho que essa seja uma boa solução para uma aplicação independente do fornecedor de banco de dados.

     

    Outra solução ocorre quando você possui ferramentas CASE que geram as classes e já possuem todos os métodos CRUD (Create, Retrieve, Update & Delete) prontos. Nesse caso, a parte de acesso a dados já está praticamente codificada e montar tudo em SP é um atraso em relação ao tempo de desenvolvimento (embora proporcione vários benefícios posteriormente). Ainda assim, muitos geradores de classe já geram os métodos em SP.

     

    Sinceramente, tenho dificuldades em elencar cenários em que stored procedures não devam ser usadas. O que posso falar com facilidade é para que você evite colocar em SPs coisas que não são de banco de dados como por exemplo geração de arquivos, formatação de páginas HTML, envio de e-mails, etc. Tais funcionalidades definitivamente não devem ficar em SP. Toda vez que uma SP executa algo que não seja recuperar e gravar dados, ela estará tornando o banco de dados mais lento para a recuperação e gravação de dados.

     

    [ ]s,

     

    Gustavo

    terça-feira, 11 de novembro de 2008 19:51
  • Bom outra pratica nao recomentada para store procedure e quando vc. precisa fazer concatenacao de comandos para usar exec ou sp_executesql, neste caso e melhor ter a contatenacao dentro da aplicacao que na proc, ( nao estou olhando o problema de sql injection ja estes procedimentos nao sao recomendados nem em proc nem em codigo ) .

     

    Abs;

     

    quarta-feira, 12 de novembro de 2008 10:20
  • Amigos,

     

    Concordo com vocês.

     

    O que eu costumo dizer para os meus alunos, stored procedure é um recurso que trabalha diretamente com o banco de dados, então devemos utilizar para manipular informações ou transações que estão diretamente relacionados com os nossos dados, não sou partidário de criar stored procedure para manipular arquivos ou fazer exportação/importação de dados entre diversos tipos de arquivos.

    quarta-feira, 12 de novembro de 2008 10:29
  • E, por favor, não colocar regras de negócios em stored procedures.

    http://ferhrosa.pfsistemas.com http://twitter.com/ferhrosa

    sábado, 2 de junho de 2012 14:27