none
Usar Stored Precedure é uma boa ideia ?

    Discussão Geral

  • Pergunto isto porque trabalhei em empresa de desenvolvimento que não usava SP porque se o cliente quebrasse o contrato os códigos do banco iriam ficar todos com o cliente, isto inclui todas as SP, triggers e por ai vai. Portanto ela vê o lado comercial das desvantagens de usar Códigos no SGBD . Alguém é de acordo com isto? é um bom negócio deixar de usar Sp deixando as vantagns e desvantagem de usar tais regras de négocio?

    Sé é ou não de acordo me expliquem porque ?

    Me digam as desvantagens e vantagens no dia a dia ao usando ou não Stored Precedure. Como segurança, manutenção e confiabilidade do sistema.

    A empresa que falo usava vb6 e sql server 2000. E eu estou desenvolendo em vb.net 2005 e sql 2005.
     
    quarta-feira, 10 de junho de 2009 01:52

Todas as Respostas

  • Charles,

    Eu acho que a maior vantagem em usar stored procedure é a manutenção e debug de problemas do sistema.
    Muitas vezes você pode fazer uma atualização no seu sistema sem precisar re-compilar código, apenas alterando as stored procedures.

    Outra grande vantagem é o fato de que todas as estações (terminais) usarem os mesmos scripts.
    No caso de uma atualização em que os scripts não estão no programa, você não precisa ir de estação em estação para atualizar o aplicativo, basta somente alterar as procs no servidor.

    Você pode criptografar suas procs (apesar de facilmente conseguir "quebrar" a criptografia).

    Não pense que colocando os scripts na sua aplicação, você estará protegendo 100% do seu código.
    A ferramenta "profiler" permite capturar os scripts que estão sendo processados.
    Não sei se ferramentas do tipo wireshark (captura de pacotes na rede) também permitam capturar código sql.

    Abraços,

    Cassiano
    quarta-feira, 10 de junho de 2009 11:45
  • Ola Charles

    Concordo com o Cassiano, e adicionando um pouco mais de informacoes a partir do sql 2005 podemos usar procs CLRs que são mais seguras pois são compiladas(dll)

    Att.
    Marcelo Fernandes
    MCP, MCDBA, MCSA, MCTS. Se útil, classifique!!!
    quarta-feira, 10 de junho de 2009 11:55
  • Bom Dia,

    Acho que essa é uma decisão difícil. Embora a maioria dos profissionais, livros e cursos indique o uso de Stored Procedures By Default acho que existe muito envolvido nessa decisão. As considerações que farei são voltadas para softwares com larga utilização e talvez não se apliquem aos "softwares de padaria".

    Prós

    O código está centralizado em um único ponto e as alterações podem ser feitas nesse único ponto (considerando que não se trata de novas funcionalidades). Se vários pontos da aplicação (ou até várias aplicações) dependem dessa SP, você tem um único lugar para "mexer" ao invés de "costurar" vários pontos da aplicação atrás de corrigir um SELECT. Embora seja uma vantagem, isso poderia ser obtido com o uso de uma arquitetura orientada a componentes e (ou) serviços

    O uso de Stored Procedures garante mais segurança para o banco de dados. Ao invés de conceder permissões direto nas tabelas, você pode conceder permissões diretamente nas SPs. Isso também evita que usuários "pluguem" um Access da vida e joguem por terra o desempenho do banco com bloqueios, relatórios, etc.

    O uso de procedures facilita a estratégia de deploy de alterações evolutivas. Mudar o código de uma SP é muito mais fácil do que compilar novamente o código e eventualmente distribuí-lo

    O desempenho de uma Stored Procedure normalmente é superior a um código TSQL na aplicação, pois, se beneficia do plano pré-compilado.

    Contras

    O código da Stored Procedure é um código que fica dentro do banco de dados e consome recursos do banco de dados. Se você precisar "crescer" terá que "crescer" o servidor do banco de dados verticalmente, ou seja, comprando uma máquina mais poderosa. Se a lógica estivesse na aplicação ou em componentes você poderia crescer verticalmente, ou seja, dividir a carga entre outros servidores.

    Stored Procedures não são compatíveis com engenharia reversa. É possível extrair seu código, mas não é possível gerar uma documentação do que elas fazem (ao contrário de objetos, métodos, etc).

    Adoro Stored Procedures, mas é bom avaliar até que ponto elas realmente são necessárias (não as indico By Default). Dependendo da arquitetura não colocaria tudo em SP, mas confesso que me assusta um banco que não tenha nenhuma SP.

    Se a sua idéia de usar ou não por conta de segurança, avalie, pois, como foi dito, é possível pegar as instruções SQL.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Como importar e exportar imagens entre o SQL Server e o File System ? – Parte I
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!601.entry


    Classifique as respostas. O seu feedback é imprescindível
    quarta-feira, 10 de junho de 2009 14:36
  • Trabalhei em sistema sem nenhuma SP, foi um susto para mim também. Vendo tais relatos achei melhor usar SP para evitar problemas de manutenção e segurança do sistema. Sei das desvantagens, mas as vantagens são maiores ao meu ponto de vista.


    quinta-feira, 25 de junho de 2009 16:25