none
Storeds usando VB.net RRS feed

  • Pergunta

  •  

    Bom dia!

     

    Preciso entender como funciona Storeds Procedures...

    Tenho q criar um exemplo em VB.net e ASP.net usando SP com parâmetros

    de entrada e saída.. Coisa simples, pode ser um tabela com 2 registros..

    É só para aprender como faz e prq usamos as SP...

     

    Obrigado.

     

    segunda-feira, 24 de setembro de 2007 13:24

Respostas

  •  

    Daniel,

     

    Para situações simples, como este seu exemplo, da forma como você fez não deve dar muita diferença, isso se a tabela for pequena e não tiver muitos índices, etc. Agora, se for usar consultas mais complexas, ligando tabelas, fazendo vários WHERE, eu recomendaria manter nessa sua proc principal somente os IFs, e colocar as consultas em si dentro de outras duas procedures. Se o IF tiver mais alternativas, coloque mais uma proc para cada forma diferente de execução.

     

    Pegou a idéia?

     

     

    Abraço

    segunda-feira, 24 de setembro de 2007 20:16

Todas as Respostas

  •  

    Olá Daniel!!!

     

    Abaixo segue partes de uma resposta que dei a outro post aqui no fórum (sobre o pq de usar SPs), depois colocarei um exemplo de SP.

     

    "A principal vantagem das SPs é a performance. Elas são otimizadas para manter cache dos planos de execução, o que já faz uma grande diferença.

     

    Depois, a administração da lógica/regras de negócio fica centralizada.

     

    A GRANDE recomendação (é quase uma lei, hehe), é manter as SPs sempre o mais curtas possíveis. Uma frase que ouvi uma vez, as SPs devem ser pequenas e atômicas, ou seja, muito rápidas.

     

    Depois disso, evitar a criação de objetos dentro das SPs, tentar usar sempre variáveis. EVITAR desvios de código (os benditos IFs...), isso acaba invalidando os planos de execução.


    Complementanto...


    O plano de execução é tipo um mapa de como o SQL irá executar a operação. Imagine que você tem uma consulta com join entre 5 tabelas e mais 3 parâmetros na clausula where. O SQL terá que encontrar qual a melhor maneira de executar essa consulta, por onde ele começa a fazer a associação das tabelas e quais índices utilizar para isso. Todas essas informações ficam dentro do plano de execução. Uma vez criado, ele vai para o cache, e pode ser reutilizado na próxima vez que o procedimento for executado.

     

    O processo de criação do plano de execução pode ser um tanto pesado, dependendo da quantidade de informações, tabelas, índices, parâmetros, etc. Então, o cache vai permitir que não seja necessário executar a criação do plano, que já existe.

     

    Sobre a "atomicidade", dê preferência a procedures que executem apenas uma tarefa. Por exemplo, se tiver uma aplicação com cadastro de clientes, criar uma procedute de insert do cliente, uma de update, uma de delete e uma de consulta. Tente evitar ao máximo a utilização de IFs, se não tiver como escapar, crie uma proc principal com os IFs e ao invés de criar ter as outras instruções nessa mesma proc, crie outras procs apenas com as instruções executadas dentro do IF. "

     

    Exemplo de procedure:

     

    Code Snippet

    -- CRIAÇÃO DE TABELA PARA EXEMPLO
    CREATE TABLE TESTE (ID INT IDENTITY(1,1), NOME VARCHAR (100))

     

    -- INSERT DE DADOS
    INSERT INTO TESTE (NOME) VALUES ('JOÃO')
    INSERT INTO TESTE (NOME) VALUES ('MARIA')

     

    -- SP DE CONSULTA POR NOME

    CREATE PROC dbo.spuConsulta
    @INICIAL VARCHAR (20)
    AS
     SELECT * FROM TESTE WHERE NOME LIKE @INICIAL
    GO

     

     


    Bom, a chamada da SP usando parâmetros, vais ter que esperar a resposta de outro colega, pois não sou programador.

     

     

    Espero ter ajudado.

     

     

    Grande abraço

     

     

    segunda-feira, 24 de setembro de 2007 13:49
  • Muito Obrigado Alexandre VM! Entendi mto bem qual é a idéia de usar SP.

    E pelo visto, vou usar muito esse recurso...

     

    []'s

     

     

    segunda-feira, 24 de setembro de 2007 14:03
  •  

    Daniel,

     

    É, com certeza é o melhor recurso relacionado a desepenho dentro do SQL. Vai ser muito bom se usares bastante as SPs.

     

    Se tiver outras dúvidas, é só retornar.

     

     

    Abração

    segunda-feira, 24 de setembro de 2007 14:08
  • Olá Alexandre VM..

     

    criei essa procedure para um teste aqui (pra aprender)...

    esse if é o seguinte...

    if @id = -1 - a pagina carrega com todos os dados(id) num dropdown

    else - somente o nome referente ao id selecionado na dropdown, vai para um textbox..

     

    O q me diz da estrutura dela? nesse caso o if está correto?

    Alguma dica?

     

     

    Code Snippet

    ALTER PROCEDURE [dbo].[final](

    @id varchar(5)

    )

    AS

    BEGIN

    if @id = -1

    select * from tb_id

    else

    select nome from tb_id where id = @id

    END

     

     

     

    Obrigado.

    segunda-feira, 24 de setembro de 2007 18:52
  •  

    Daniel,

     

    Para situações simples, como este seu exemplo, da forma como você fez não deve dar muita diferença, isso se a tabela for pequena e não tiver muitos índices, etc. Agora, se for usar consultas mais complexas, ligando tabelas, fazendo vários WHERE, eu recomendaria manter nessa sua proc principal somente os IFs, e colocar as consultas em si dentro de outras duas procedures. Se o IF tiver mais alternativas, coloque mais uma proc para cada forma diferente de execução.

     

    Pegou a idéia?

     

     

    Abraço

    segunda-feira, 24 de setembro de 2007 20:16
  • Ok.. nesse caso é só isso mesmo.

    Como disse, é para aprender, mas vou ter q usar aqui no meu trabalho..

     

    Vlw pelas dicas, serão mto úteis..

     

    Obrigado mais uma vez...

     

    []'s

     

    segunda-feira, 24 de setembro de 2007 20:20
  •  

    Legal Daniel,

     

    Estamos aqui exatamente para transmitir nossa experiência. Isso é muito gratificante.

     

    Quando quiser trocar mais idéias, estamos aqui.

     

     

    Abraço

    segunda-feira, 24 de setembro de 2007 20:33