SQL no código x Stored Procedures

11/10/2014

0

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

Fernanda Acacia

Responder

Posts

13/10/2014

Clayton Silva

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

13/10/2014

Fernanda Acacia

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

14/10/2014

Marisiana Battistella

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

14/10/2014

Fernanda Acacia

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

14/10/2014

Marisiana Battistella

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

14/10/2014

Fernanda Acacia

Ta certo Marisiana, obrigada pelas dicas e boa tarde.
Responder

14/10/2014

Marisiana Battistella

Por nada!
Sempre é bom poder ajudar!
Responder

05/11/2014

Maria Araújo

Desculpem interferir, mas tive base de dados na faculdade, mas não exploramos nada do que se tem falado por aqui.
Como gostei muito da matéria estou desenvolvendo mais esse conhecimento.
Contudo, seguindo este tópico tive uma dúvida em relação ao CRUD.
Eu criei procedures para tal, na BD, mas Ronaldo disse

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

Fiquei baralhada com isso
Responder

05/11/2014

Ziobello

Eu aprendi muito com essa conversa, tinha muitas informações úteis neste fórum obrigado
[url]http://celularpecas.com.br/[/url]
Responder

05/11/2014

Fernanda Acacia

Desculpem interferir, mas tive base de dados na faculdade, mas não exploramos nada do que se tem falado por aqui.
Como gostei muito da matéria estou desenvolvendo mais esse conhecimento.
Contudo, seguindo este tópico tive uma dúvida em relação ao CRUD.
Eu criei procedures para tal, na BD, mas Ronaldo disse

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

Fiquei baralhada com isso


Pelo que entendi ele quis dizer que só feito somente pela aplicação.
Responder

06/11/2014

Maria Araújo

Fernanda quer dizer então, que na aplicação em vez de executar procedures (CommandType.StoredProcedure, "nome procedure")
executa (CommandType.Text, "instrução SQL").

Poderá alguém ajudar com outro assunto: Quando e porquê usar functions?
Já çi sobre isso, mas os comentários aqui são sempre mais construtivos
Responder

06/11/2014

Fernanda Acacia

Eu entendi assim, nao é em todo caso que se utiliza stored procedure?
Maria, nao me leve a mal, mas é bom abrir um outro post.
Responder

07/11/2014

Cleverson

Gente e sempre melhor validar dados na aplicação, se for por motivo de validação não vale usar stored procedures (Minha opinião).

Supondo que temos (Uma table Clientes com todos os campos comuns a ela):

DELIMITER $$

CREATE PROCEDURE inserirCliente(IN idCliente INT, IN Nome VARCHAR(32)) DETERMINISTIC
BEGIN
  IF(SELECT `id` FROM `Clientes` WHERE `id` = idCliente) > 0) THEN
    UPDATE `Clientes` SET `nomeCompleto` = Nome;
  ELSE
    INSERT INTO `Clientes` (`id`, `nomeCompleto`) VALUES (NULL, Nome);
  END IF ;
END $$

DELIMITER ; 



Creio que simplesmente você possa enviar o dado, simplesmente se ele existir atualiza, se não insere na table.
Sem falar procedimentos para pesquisa em banco de dados (Que normalmente contem um SQL 'Pequeno') dependendo da aplicação.

Segurança, rapidez (Por enviar somente 1 comando ao BD) e outros benefícios.

Ops já ia esquecendo, você pode usar a procedure em varias aplicações (JAVA, .NET, DELPHI, Web e todas mais)
Basta somente chamar os procedimentos.

vlw
Responder

07/11/2014

Fernanda Acacia

Melhor na aplicação, fechado Smiley, se o sistema não muito grande, complexo é melhor mesmo.
Responder

09/11/2014

Soeuseijothaz

Minha humilde contribuição.

Certas empresas que trabalhei era obrigatório o uso de stored procedures, pois fica mais fácil para os DBA´s controlar a performance do BD e o que esta sendo executado.
Outra vantagem é que as SP´s ficam pré-copiladas o que da um gás na hora de executar.

A desvantagem é que se existir alguma regra de negócio na SP ela fica encapsulada.
Estando tudo na aplicação fica mais legível.
Responder

Assista grátis a nossa aula inaugural

Assitir aula

Saiba por que programar é uma questão de
sobrevivência e como aprender sem riscos

Assistir agora

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar