locked
Utilizar SQL Stored Procedures ou Views, para efeitos de consulta. Dúvida de performance e redundância! RRS feed

  • Pergunta

  • Olá, tenho aqui uma situação que gostava de partilhar com vocês e gostaria de obter as vossas opiniões.

    É assim, tenho uma BD muito complexa em Access que vai para SQL, é a minha tarefa. O problema, é que na BD Access actual, as consultas parecem-me ser algo redundantes.

    Imaginem, uma consulta serve-se de alguns dados de outra consulta, que por sua vez se serve de alguns dados de outra consulta, que por sua vez se serve de dados de uma ou duas tabelas em Access.

    A ideia é eliminar esta redundância e complexidade, fica tudo num procedimento ou view. Nesta BD tudo se resume a consultas, e por vezes, em variadíssimos procedimentos que possa vir a criar, se for especifico para cada um, vai surgir muita repetição da mesma tarefa, à mesma tabela, mas seleccionando dados distintos (Ex.: campo idade, para um procedimento, preciso de dados relativos a menores de 40, em outro, maiores que 40, para explicar melhor!).

    Tenho então 3 opções:
    Crio procedimentos de grande porte directos às tabelas, e pronto;
    Crio procedimentos auxiliares para efeitos de acções que se repitam várias vezes, de forma a serem consultados por procedimentos de maior porte;
    Crio views de suporte a procedimentos de grande porte;

    Já ouvi rumores de que a view é algo pesada, na prática é mais uma query que é feita antes de retornar qualquer tipo de informação! Será mais eficaz procedimentos só?

    E no caso de ter selects que se repitam várias vezes, será melhor uma view? Se usar um procedimento dentro de outro como utilizo os dados obtidos do segundo no primeiro?

    Agradeço as vossas opiniões, muito obrigado!

    quinta-feira, 10 de maio de 2007 10:38

Todas as Respostas

  • Bom dia

     

    Minha sugestão é que dependendo do caso pode ser interessante fazer um misto de Function´s e Procedures. Mas vale lembrar que muito mais importante é você fazer uma análise criteriosa para evitar ao máximo a redundância e a complexidade também, para você obter os dados de uma uma procedure em outra basta você criar um parâmetro de output na primeira e utilizá-lo na segunda. Segue abaixo um exemplo

     

     

    Create Procedure usp_Soma(@vl1 int,@vl2 int,@Resultado int output) as

    Begin

       If @vl1 is null

         Set @vl1 = 0

     

       If @vl2 is null

          Set @vl2 = 0

     

      Set @Resultado = @vl1 + @vl2

    end

    go

     

    Create Procedure usp_multiplica(@vl1 int) as

    Begin

       If @vl1 is null

          Set @vl1 = 100

     

     

    Declare @multiplicador int

     

    Exec usp_Soma 10,200, @Multiplicador Output

     

    Select @Vl1 * @multiplicador

     

    end

     

     

     

     

    Espero ter ajudado

    quinta-feira, 10 de maio de 2007 11:07
  •  

    Concordo com o Anderson, mas gostaria de expressar a minha opinião.

     

    Acredito que a utilização de Stored Procedures, Functions ou Views realmente depende da necessidade, em particular eu utilizo bastante as stored procedures do próprio SQL Server e também as que desenvolvo quando deseja realizar um processamento grande de informações.

     

    No caso da view, procuro centralizar a utilização deste recurso em meus sistemas que precisam disponibilizar consultas remotas, entre as filias da empresa que trabalho, ou seja, quando é necessário acessar através da Extranet crio um view especifica para esta utilidade, ou para histórico de movimentação.

    quinta-feira, 10 de maio de 2007 11:40
  • Concordo com o Junior e deixo alguns esclarecimentos.

     

    View é uma tabela virtual que representa os dados de uma ou mais tabelas (query batch). Você pode executá-la da seguinte forma:

    Select * from View_Nome

     

    Stored Procedure é um ou mais SQL Statements armazenado que pode(m) ser executado(s) de uma única vez. Você pode executar da seguinte forma:

    Exec SP_Procedure

     

     

    Espero ter contribuído

    quinta-feira, 10 de maio de 2007 12:05
  • Desde já fico muito grato pelo vosso contributo, que foi aceite e percebido com clareza. Resta-me apenas uma pequena dúvida:

    A nível de selecção de dados, são mais rápidas as Views ou os Stored Procedures? Li algures que as views são um pocuo lentas, uma vez que, embora sejam tabelas virtuais, constituem a execução de mais uma query!

    Tenciono de facto utilizar stored procedures, uma vez que estou habituado, permitem fazer uma série de queries num só procedimento, e são fáceis de instalar e de utilizar!

    Mais uma vez muito obrigado a todos!
    sexta-feira, 11 de maio de 2007 10:49
  • Bom dia

     

    Geralmente as SP´s podem ser um tanto quanto mais rápidas por gerarem um plano de execução, contudo vai depender de uma série de fatores como por exemplo os parâmetros que são que são passados o que tem um impacto direto sobre o tempo para a geração de um novo plano de execução.

     

     

     

     

     

    Espero ter ajudado

    sexta-feira, 11 de maio de 2007 10:55
  •  

    Concordo com você Anderson.

     

    sexta-feira, 11 de maio de 2007 12:04
  • De facto concordo também, no meu caso nunca teremos mais que 4 a 7 parâmetros como entrada no stored procedure! Pela pouca experiência que tenho, não me parecem ser muitos parâmetros, ou estarei enganado?

    Que outras técnicas posso explorar para tornar o sistema mais performante?Trigers ainda são mais lentos no geral que procedures certo?(embora mais seguros)...aceito de bom agrado sugestões e agradeço a vossa constante intervenção, um abraço!
    quinta-feira, 17 de maio de 2007 10:37
  • Ribeiro, a trigger irá permitir que o banco de dados realize alguma tarefa específica quando ocorrer alguma manipulação no seu banco de dados. Não vejo muito como substituir uma procedure por uma trigger. São aplicações diferentes.
    []´s! Fabio
    quinta-feira, 20 de janeiro de 2011 21:39
  • Ribeiro,

    Qual seria a sua ideia em utilizar a trigger no lugar da procedure?


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    quinta-feira, 20 de janeiro de 2011 23:38