SQL no código x Stored Procedures
11/10/2014
0
Fernanda Acacia
Posts
11/10/2014
Ronaldo Lanhellas
1 - Um Controle de numeração customizado de contrato. Você pode querer que cada contrato gerado (inserido) tenha um número personalizado e para isso pode usar stored procedures em conjunto com triggers.
11/10/2014
Fernanda Acacia
11/10/2014
Ronaldo Lanhellas
Considere que um processamento por uma stored procedure é mais rápido que um processamento de um SQL usado na aplicação. Isso porque a aplicação ainda tem que chamar a conexão com o banco de dados, estabelecer e estabiliza a mesma para só então executar o comando. Sobrecarregar ? Se for um bom banco de dados você nem sentirá a diferença de uma trigger sendo disparada.
11/10/2014
Fernanda Acacia
eu queria apenas para as operações basicas do banco.
11/10/2014
Ronaldo Lanhellas
eu queria apenas para as operações basicas do banco.
Depende muito fernanda do tipo de regra de negócio que você está aplicando. Geralmente CRUD (operações básicas) são feitas na aplicação e não no banco, isso porque o CRUD por mais básico que seja pode exigir tratamentos mais complexos.
11/10/2014
Fernanda Acacia
11/10/2014
Ronaldo Lanhellas
Fique a vontade. As operações que você acha que pode exigir a criação de stored procedures são aquelas no qual a sua aplicação não precisa saber, como é o caso da numeração de contratos que citei, a aplicação não precisa saber se o banco está gerando um número de contrato através de uma stored procedure, ela apenas usa.
Não quer dizer que coisas complexas fiquem na aplicação ou no banco, não existe essa divisão. O caso do CRUD que citei adapta-se melhor na aplicação, mas podem existem outros casos que o melhor é o banco.
11/10/2014
Ronaldo Lanhellas
Se tratando de CRUD, seja simples ou não, deixe por conta da aplicação.
13/10/2014
Fernanda Acacia
13/10/2014
Clayton Silva
Porém store procedures são mais recomendadas para querys mais complexas.
Mas tudo depende da aplicação e o cenário aplicado.
Hoje em dia as ORMs fazem tudo, então esse negócio de store vs códigos não é muito discutida hoje em dia.
13/10/2014
Fernanda Acacia
Isso depende mais do programador, projeto, equipe?
e por que vc usa com frequencia os stored procedure?
13/10/2014
Clayton Silva
A desvantagem é que a manutenção é maior. Pois a programação fica no banco de dados.
É uma boa quando se tem um DBA que cuide do código. Ele pode fazer alterações de performance sem que precise mecher na aplicação.
Se o código fica na aplicação, o DBA tem que pedir para o programador alterar.
Porém se o programador precisa alterar ele pode terá que ir no BD alterar ou solicitar o DBA que faça, caso o desenvolvedor não tenha acesso.
13/10/2014
Ronaldo Lanhellas
Bom, trabalhei com grandes projetos e em todos usamos CRUD na aplicação, nunca no banco, por mais simples que seja.
Clique aqui para fazer login e interagir na Comunidade :)