stored Pocedures X t-sql no código

Question

Pessoal,

 

Surgiu uma discussão feia aqui na empresa onde eu trabalho referente a stored Pocedures  X  t-sql no código.

Eu defendo que as stored Pocedures  são melhores porque diminuem o trafego de rede, porque o SQL cria um execution plan melhorando a performance, por questões de segurança etc.

Porem tem algumas pessoas que defendem o contrario.

O que vocês acham??

Conhecem alguma referencia que prove que eu estou certo? Ou errado? Rsrs.

Obrigado a todos!

Answer 1

 

Bom, na maioria dos casos uma proc e melhor que um TSQL, existem varios pontos alem do cache armazenado, por exemplo uma proc pode ser pior que um TSQL se ela nao puder manter o plano armazenado, procs que usam tabelas temporarias, comando set vao ser recompiladas a toda a hora, e a performance vai ser pior que a de uma instrucao TSQL direto, mais se vc. analisar por exemplo uma aplicacao a proc pode ser ponto de referencia em seguranca, pois os parametros estarao predifinidos e passados via parameter nas rotinas evitando injecao de comandos sql, outra vamtagem e que se vc. precisar alterar o codigo de uma proc em que o result set sera o mesmo nao precisara alterar o aplicativo.

 

mais vc. deve olhar tambem para as funcoes que retornam um table sao bem uteis em alguns casos tabem.

 

minhas consideracoes.

Answer 2

Complementando...

 

Um ponto miuto importante também na utilização do código é a facilidade para manutenção ou solução de problemas. Imagine que vc error na hora de fazer um join, ou colocou uma coluna a menos ou ainda colocou o nome da tabela errada.....em fim, qualquer coisa do tipo.

 

Com o código na aplicação vc precisa abrir o fonte, corrigir o problema, compilar um novo .exe e distribuir. Se a sua aplicação é comercial, seu cliente vai ficar puto por ter que ficar alterando o .exe a cada mudança.

 

Se vc estiver usando procedure....é só alterar a proc e o problema está resolvido !! Muito mais simples e sem stress.

 

Bom.... mas tem gente que ainda gosta de desenvolver como na época do Access

 

 

Nilton Pinheiro

www.mcdbabrasil.com.br

 

 

Answer 3

Saccolino,

 

Primeiramente este tipo de discussão acaba fazendo com que as dúvidas e opiniões divergentes se torne ainda maiores.

 

Quando se fala em stored procedure existe uma velho ditado, que este tipo de procedimento que é executado diretamente no servidor tem como objetivo aumentar a performance do processo que esta em execução. Com certeza isso é uma verdade comprovada, mas não somente devemos se basear nesta questão para definir a utilização deste tipo de recurso.

 

Outra fator importante é o processo de manutenção e também o quando isso facilita no momento de melhorar a flexibilidade que o SQL Server terá para trabalhar diretamente com o plano de execução, como também fazendo uso do cache de armazenamento isso tende a melhorar ainda mais. Mas a segurança em se utilizar uma stored procedure é ainda maior pois todas as informações que estão sendo processadas e manipuladas estão trabalhando de forma única e exclusiva no Servidor SQL Server, isso elimina em muito o risco relação a segurança dos dados.

 

Os comandos T-SQL são muito práticos e de facil utilização e compreensão tanto para quem esta montando o código como também para o SQL Server, quando vai executar fazendo o uso do Query Optimizer. Uma vantagem em se utilizar T-SQL é possível de criar querys dinamicas, como também quando temos a necessidade de executar um pequeno script.

 

Bom, o que eu gostaria de dizer é isso, talvez não tenha muita lógica, acredito que o melhor mesmo é procurar a cada dia trabalhar com estes dois recursos, e com o passar do tempo definir o qual se entenda para a sua necessidade ser mais indicada.

Answer 4

Boa Tarde,

 

Quando um desenvolvedor diz que não utiliza stored procedures e apenas consultas diretamente ao banco (independente do argumento), costumo argumentar conforme o diálogo:

 

Desenvolvedor: Não utilizo stored procedures pelo "motivo X" (geralmente o motivo não é convincente)

 

DBA: Você sabia que elas podem ter um desempenho bem melhor por conta do plano de execução ? Que elas podem melhorar a segurança e facilitar as alterações ao invés de recompilar o código ?

 

Desenvolvedor: Ah é verdade, mas é que meu gerador de classes já faz todo o mapeamento objeto relacional só consultando as tabelas e pra eu colocar stored procedure ia ter que alterar um monte de coisa e ia gastar um tempão.

 

DBA: Realmente tem esse lado, mas não valeria a pena investir um pouco mais nisso por conta dos benefícios ?

 

Desenvolvedor: Nunca tive problema em desenvolver dessa forma. (Nessa hora o DBA quer matá-lo, mas provavelmente não fará isso porque se o fizer o desenvolvedor vai falar que o DBA está "atrasando" o projeto)

 

DBA: Você conhece bem orientação a objeto ?

 

Desenvolvedor: Claro, com certeza. Qualquer desenvolvedor que se preze tem que conhecer.

 

DBA: Interessante, queria fazer uma pergunta sobre isso. Você pode me ajudar ?

 

Desenvolvedor: Com certeza. Pode mandar (possivelmente convencido achando que ganhou a razão no caso da SP)

 

DBA: Ouvi dizer que toda vez que a gente declara uma classe, é importante criar os métodos GET e SET para as propriedades. Por que a gente faz isso ?

 

Desenvolvedor: Sim, com certeza. Toda vez que uma classe tem uma propriedade, é preciso criar os métodos acessores GET e SET para manipulá-las. Você até poderia acessar a propriedade diretamente, mas aí, se mudar alguma regra ou você precisar fazer uma validação, vai precisar mudar todo o código. Também não é seguro acessar a propriedade diretamente.

 

DBA: Ahhhhhh. Vamos ver se eu entendi. Se eu tiver uma classe Pessoa com a propriedade idade, eu vou ter que criar o GET e o SET para retornar. Eu até poderia ir direto na propriedade, mas aí eu poderia colocar uma idade negativa e com o SET eu poderia validar a idade antes de substituir o valor da propriedade. Também pensei numa classe chamada produto que tem uma propriedade chamada margem de lucro. Eu preciso colocar o GET para que ninguém consiga retornar essa propriedade já que é um dado valioso. A propriedade tem que existir, mas ninguém pode manipular ela diretamente. É isso mesmo ?

 

Desenvolvedor: Sim, é exatamente isso. Acho que você entendeu

 

DBA: Bacana, acho que realmente trabalhar com o GET e o SET é importantíssimo mesmo. Parece que acessar as propriedades diretamente pode ser trágico. Se mudar alguma regra você vai ter que sair alterando todo o seu código.

 

Desenvolvedor: Essa é a idéia

 

DBA: Estou fazendo uma analogia aqui. As suas classes vão virar tabelas no banco não vão ?

 

Desenvolvedor: Sim, com certeza. Cada propriedade da classe vira um campo de uma tabela na média

 

DBA: E é importante proteger as propriedades da manipulação direta certo ?

 

Desenvolvedor: Certo

 

DBA: Então se você se preocupa tanto em colocar uma camada a mais nos seus métodos de leitura (GET) e escrita (SET) por vantagens muito bem claras (mudanças nas regras e segurança), por que não fazer isso no banco ? Se você acessa as tabelas diretamente, basta mudar algumas tabelas para quebrar sua aplicação. Se você acessa as tabelas diretamente você poderá ver informações que teoricamente não deveria (tipo a margem de lucro). As stored procedures funcionam exatamente como o GET e o SET da orientação a objeto só que além dos benefícios ainda ganhamos em desempenho, facilidade na administração de privilégios, e um maior controle do DBA na proposta de melhoria de código, indexação, etc. Você não estaria se contradizendo em não utilizar stored procedures ? Fica parecendo até que você tá pensando na "programação" estruturada

 

Desenvolvedor: (Puto da vida). Não tem nada a ver...

 

DBA: (Apenas pensando) Então me explica qual parte que não tem a ver

 

Bom, acho apenas que como diria o Nilton, tem gente que ainda gosta de programar na época do Access. São justamente esses programadores que podem passar boa parte do tempo dando manutenção num sistema (quando não engessá-lo) simplesmente porque não se tem a menor idéia de que páginas ou formulários chamam que tabelas, porque o código fonte de produção (compilado) não é igual ao do Source Safe (e por isso não se pode mudar o banco) e por aí vai uma lista de entraves no banco de dados.

 

Existe sim evidências (se é que ainda é preciso alguma evidência) de que camada de acesso à dados deve sempre ser feita via stored procedures. Você poderá encontrar essa evidência no material do curso 2782A - Designing Microsoft SQL Server 2005 Databases no capítulo 5 (Designing a Database Access Strategy). Se você tiver os Training Kits para as provas de MCITP (Database Developer) também verá que isso é muito comentado. Nada melhor do que evidências do próprio fabricante.

 

[ ]s,

 

Gustavo

Answer 5

 

Esse assunto reeeealmente é muito bom. Poderia até mesmo ser um bom assunto para discutir numa mesa de bar, hehehe.

 

Em geral, como todo bom DBA, recomendo a utilização de procedures.

 

Mas, ao mesmo tempo, é bom saber usar as procedures. Não adianta de nada fazer tudo sobre procedures sendo que elas não ajudam em nada no desempenho (que considero o principal motivo para usar elas).

 

Uma das primeiras coisas que aprendi sobre procedures, e que aplico até hoje, consiste basicamente numa frase dita por um atigo chefe: "As procedures deve ser pequenas e atômicas"!!

 

Isso significa que a procedure de ser criada para fazer uma única tarefa, evitar ao máximo utilizar desvios de códigos (IFs) dentro das Procs, tentar manter o código o mais simples o possível. Muitos podem dizer que pode ser um grande trabalho criar várias procedures, mas, acho que esse também é um trabalho para o DBA, criar boas procedures, com ótimo desempenho.

 

Recomendo tirar um tempo para ler esse texto, muito bem escrito:

http://talibamartins.wordpress.com/2007/08/24/vantagens-de-um-dba/

 

 

 

Abraço!!!