Array
(
    [0] => stdClass Object
        (
            [Votos_Balanceados] => -1
            [id] => 500200
            [titulo] => SQL no código x Stored Procedures
            [dataCadastro] => DateTime Object
                (
                    [date] => 2014-11-05 09:18:22
                    [timezone_type] => 3
                    [timezone] => America/Sao_Paulo
                )

            [isFirstPost] => -1
            [idUsuario] => 394606
            [status] => A
            [isExample] => 
            [NomeUsuario] => ziobello
            [Apelido] => 
            [Foto] => 
            [Conteudo] => Eu aprendi muito com essa conversa, tinha muitas informações úteis neste fórum obrigado
[url]http://celularpecas.com.br/[/url] ) )

SQL no código x Stored Procedures

Fernanda Acacia
   - 11 out 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?

Ronaldo Lanhellas
   - 11 out 2014

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.

Fernanda Acacia
   - 11 out 2014

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

Ronaldo Lanhellas
   - 11 out 2014


Citação:
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.

Fernanda Acacia
   - 11 out 2014

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.

Ronaldo Lanhellas
   - 11 out 2014


Citação:
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.

Fernanda Acacia
   - 11 out 2014

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?

Ronaldo Lanhellas
   - 11 out 2014


Citação:
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.

Fernanda Acacia
   - 11 out 2014

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

Fernanda Acacia
   - 11 out 2014

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

Ronaldo Lanhellas
   - 11 out 2014


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


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

Fernanda Acacia
   - 13 out 2014

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

Clayton
   - 13 out 2014

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.

Fernanda Acacia
   - 13 out 2014


Citação:
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?

Clayton
   - 13 out 2014

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.

Ronaldo Lanhellas
   - 13 out 2014


Citação:
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.

Clayton
   - 13 out 2014

CRUD não vale o trabalho, se faz fácil com qualquer ORM, mas em projetos onde performance é exigida vale a pena, principalmente com querys complexas.

Mas depende do que cada projeto demande. Tem prós e contras em qualquer forma adotada.

Fernanda Acacia
   - 13 out 2014

Clayton, estou percebendo que isso pode gerar uma certa confusão, DBA e Programadores, um pedindo para o outro...complicou hein. rsrsrs.

Ronaldo e Clayton, mais uma: eu não tinha percebido o grau de importancia e esqueci totalmente de um detalhe "equipe".

Marisiana
   - 14 out 2014

Concordo com o que Clayton mencionou!
Isso não gera confusão Fernanda... Essa é uma ótima forma de se trabalhar pois o foco principal é a qualidade das aplicações, seja em performance ou em manutenção. Só vejo pontos positivos em utilizar isso como padrão de desenvolvimento.

Fernanda Acacia
   - 14 out 2014

Pensei assim, e pensei mais um pouco, se tudo for programado entre a equipe tambem não vejo o por que de ter "confusão". mas a principio pensei nas dificuldades.

Marisiana
   - 14 out 2014

Acredite que tudo se torna mais fácil!
Você pode concentrar as procedures e functions que se destinam para uma mesma aplicação ou para um mesmo assunto que está sendo tratado em packages, isso facilita mais ainda o trabalho e a compreensão dos códigos.
Não esqueça de colocar um comentário em cada procedure e function justificando a regra que ele atende, pois a mesma pode ser utilizada em mais de um local da aplicação.