SQL no código x Stored Procedures

11/10/2014

Estou fazendo alguns exemplo de inserção de dados via console, estou vendo outras formas de fazer isso, vi que existe a possibilidade de fazer utilizando Stored Procedure, existe vantagem em inserir Stored Procedures para fazer operações no banco de dados?

Fernanda Acacia

Respostas

11/10/2014

Ronaldo Lanhellas

Bom, como na maioria das vezes, a resposta é depende. Stored Procedures são nada mais do que procedimentos armazenados, e são muitos úteis quando você quer tirar a responsabilidade da aplicação sobre alguma tarefa. Vou lhe dar um exemplo onde é melhor aplicar uma stored procedure do que usar um controle na aplicação:

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.
Responder Citar

11/10/2014

Fernanda Acacia

Sim, realmente ele tira a responsabilidade da aplicação, mas fazendo isso ele pode sobrecarregar o banco de dados?
Responder Citar

11/10/2014

Ronaldo Lanhellas

Sim, realmente ele tira a responsabilidade da aplicação, mas fazendo isso ele pode sobrecarregar o banco de dados?


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.
Responder Citar

11/10/2014

Fernanda Acacia

Então é melhor utilizar Stored Procedure, sendo SQL Server e C# ou isso vai depender? e de que se for depender de algo?

eu queria apenas para as operações basicas do banco.
Responder Citar

11/10/2014

Ronaldo Lanhellas

Então é melhor utilizar Stored Procedure, sendo SQL Server e C# ou isso vai depender? e de que se for depender de algo? 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.
Responder Citar

11/10/2014

Fernanda Acacia

Olha só, estarei progredindo nos questionamentos Ronaldo, se me permitir é claro, espero não estar sendo chata, essas operações no banco, deixo para fazer algo mais complexo?
Responder Citar

11/10/2014

Ronaldo Lanhellas

Olha só, estarei progredindo nos questionamentos Ronaldo, se me permitir é claro, espero não estar sendo chata, essas operações no banco, deixo para fazer algo mais complexo?


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.
Responder Citar

11/10/2014

Fernanda Acacia

Resumindo, em um crud simples é necessario ou não?
Responder Citar

11/10/2014

Fernanda Acacia

Resumindo, em um crud simples é necessario ou não?
Responder Citar

11/10/2014

Ronaldo Lanhellas

Resumindo, em um crud simples é necessario ou não?


Se tratando de CRUD, seja simples ou não, deixe por conta da aplicação.
Responder Citar

13/10/2014

Fernanda Acacia

Otimo então Ronaldo, pelo menos esteticamente parecia ser melhor usar stored procedures, mas as aparencias enganam.
Responder Citar

13/10/2014

Clayton

Eu prefiro sempre usar store procedures até para o básico.
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.
Responder Citar

13/10/2014

Fernanda Acacia

então esse negócio de store vs códigos não é muito discutida hoje em dia.


Isso depende mais do programador, projeto, equipe?

e por que vc usa com frequencia os stored procedure?
Responder Citar

13/10/2014

Clayton

Pq o meu foco nos meus projetos é segurança seguido de performance.
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.
Responder Citar

13/10/2014

Ronaldo Lanhellas

Otimo então Ronaldo, pelo menos esteticamente parecia ser melhor usar stored procedures, mas as aparencias enganam.


Bom, trabalhei com grandes projetos e em todos usamos CRUD na aplicação, nunca no banco, por mais simples que seja.
Responder Citar