none
Uso de stored procedure RRS feed

  • Pergunta

  • Olá pessoal,
    
    Preciso da opinião técnica de vcs...
    Estou desenvolvendo uma aplicação web gigantesca. Estou criando diversas 
    stored procedures para selects, updates, deletes, etc...
    
    As procedures são todas escritas com seus parâmetros, campos, valores, e até 
    mesmo wheres dinâmicos (como parâmetro).
    
    Isso está me dando muito trabalho e me preocupa qt à manutenção, pois em 
    alguns casos, se isso acontecer, eu terei que alterar a tabela, o código e as 
    stored procedures envolvidas com a tabela alterada.
    
    Então pensei na procedure abaixo:
    
    CREATE PROCEDURE GG_SP_EXECSQL (@SQLStatement varchar(8000)) AS 
    EXEC(@SQLStatement)
    GO 
    
    Ou seja, monto toda a instrução no código e passo como parâmetro. Assim além 
    de facilitar a codificação de condições, se necessário, faço a manutenção em 
    um único local.
    
    O que vcs acham deste método? É prático e funcional? Tem algum inconveniente?
    
    Agradeço qq ajuda.
    quarta-feira, 4 de outubro de 2006 13:29

Respostas

  • Olá Ramon,

    Recentemente passei por uma situação parecida com a sua.

    Me recomendaram uma leitura um tanto demorada, mas muito válida, segue o link:

    http://www.sommarskog.se/dyn-search.html

    Neste você irá encontrar informações sobre as diversas formas de utilização de SQL Dinâmico. Realmente, existem várias formas de fazer, mas cada uma destas tem alguma vantagem ou desvantagem sobre a outra.

    A forma que realmente achei mais interessante, é a utilização da "sp_executesql". Onde você pode passar exatamente qual query quer realizar, parâmetros que serão usados e valores para parâmetros.

    Bem, espero ter cooperado.

    Abs.

    quinta-feira, 5 de outubro de 2006 21:30

Todas as Respostas

  • Ramon,

    Ao meu ver não terá vantagem, pelo fato que, se não fará manutenção direto no banco ou pelo VS.NET não tem necessidade, faça a consulta dentro do código mesmo.

    A intensão das SPs é:

    Melhorar a performance, já que no banco quando executadas uma vez ele fica em cache, melhorando nas próximas solicitações;

    Melhorar justamente a manutenção já que todas as SPs vão estar independe do código/dll/exe de forma que pra alterar basta alterar e executar o update, depois poderá rodar o app novamente que já estará automaticamente atualizado, sem precisar uma nova compilação.

    Evitar problemas de segurança como Sql Injection (XSS), justamente na utilização de parâmetros além de melhorar sua legibilidade

    E finalizando, aumentas as possibidades e facilidade de uso do Transact-Sql, na qual poderá utilizar de todos os seus recursos... que numa query conecatenada ficaria inviável.

     

    Sobre a questão da manutenção, não vejo segredo e dificuldade, sinceramente é muito mais fácil, pelo fato de que você tem todas as querys em um só lugar...

    E pra fazer backup, apenas gere um script do danco com todas as opções, indexes, object dependecies, etc, etc, etc...

     

     

    Então, essa é minha opinião, já utilizei das duas formas e estou colocando minha opnião, outros podem descordar.

     

     

    Então é isso, espero ter ajudado!

    quarta-feira, 4 de outubro de 2006 13:42
  • Olá Ramon,

    A questão é a seguinte, este meio que vc pretende usar certamente te dará dor de cabeça mais para frente devido a ser um sistema "gigante" como vc disse. Vc esta completo de razão quando diz que ao alterar uma tabela tem que alterar todo o código, porem analise os itens abaixo.
    Normalmente deixamos tudo no banco de dados pelos seguintes motivos:
    1 - Para migrar o banco de dados, digamos de um Oracle 8i para um Oracle 10g não será necessário mexer em nenhuma linha de código do Sistema
    2 - Para migrar o sistema do Visual Studio 2005 para o Visual Studio 2007 não será necessário mexer em nada no banco de dados
    3 - Uma SP do sistema pode ser usada por vários modulos do sistema, por exemplo, várias telas do seu sistema usam uma combo que lista os usuarios, logo essa combo utiliza uma SP de selação de usuarios que será sempre igual para todas as combos, logo ao corrigir um erro na SP ele corrige em todas combos, sem precisar mexer no código.

    essas são algumas situações que a SP ajuda muito

    Sugiro que seja continue com sua estrutura de várias SPs para não ter dor de cabeça mais para frente.

    Se tiver mais dúvidas pode perguntar

    Se esta foi a resposta para seu Post marque como Respondido
    Att

    Henrique Gurgacz

    quarta-feira, 4 de outubro de 2006 13:43
  • Ramon,

    Se aprofundar-se muito no assunto, a Stored Procedure é um objeto existente dentro do banco de dados que tem como função facilitar a manutenção, evitando muitas vezes a necessidade de alterar a aplicação, bem como, proporcionar um maior desempenho.

    Agora, levando-se em consideração a sua necessidade, acredito que utilizar um SP do próprio SQL Server, não venha a apresentar qualquer tipo de melhoria, mas sim, um nível do processamento maior, pois como esta procedure é do SQL Server, no momento em que for executada, o servidor SQL Server deverá primeiramente localizar ela dentro do seu banco Master, e depois obter o seu parâmetro para posterior execução.

    Mas isso as vezes torna-se imperceptivél, antes de mais nada é importante fazer uma análise.

    quarta-feira, 4 de outubro de 2006 14:22
  • Obrigado pela opinião de vcs.

    Quanto a manutenção, logicamente ng projeta um BD para ficar alterando ele a todo momento, mas elas existem ao longo do tempo, principalmente em um portal web onde são agregados módulos e funcionalidades rotineiramente.

    Uso classes, então a codificação das condições e instruções SQL são concentradas, facilitando qualquer modificação.

    Por exemplo, para preencher uma combo, uso uma SP com WHERE e ORDER BY dinâmico, conseqüentemente faço um EXEC SELECT ..., pois monto a instrução SQL a ser executada dentro do SP. Não sei se é vantagem, mas fiz isso justamente para não ter que construir uma SP para tipo de ordenação que preciso... Imagine se forem 5, 10, e assim vai? Então fiz uma única SP onde passo a instrução WHERE e o ORDER BY...

    E justamente por estar usando EXEC na maioria dos meus SELECTs que pensei na SP genérica... Pois qt a UPDATEs e DELETEs acho que não há problema em fazer um EXEC...

    Então a minha dúvida mesmo é se fazer uma SP genérica, onde faço EXEC de qualquer instrução SQL, evitando a construção de centenas de SPs, que será o meu caso, tem algum inconveniente técnico (performance, etc.). Quanto à manutenção não será problema, pois está tudo documentado nos parâmetros de cada função das classes. Ou seja, existe algum problema relevante nesta proposta (entre ter que optar por criar uma SP e centenas delas...)?

    Agradeço, mais uma vez, pela atenção.

     

    quarta-feira, 4 de outubro de 2006 14:30
  • Olá Junior,

    Então vc acha, que no meu caso, como vou ter que construir centenas de SPs e a maioria delas parametrizadas, não compensa? Seria melhor usar a codificação direta?

    quarta-feira, 4 de outubro de 2006 14:33
  • Olá Ramon,

    Recentemente passei por uma situação parecida com a sua.

    Me recomendaram uma leitura um tanto demorada, mas muito válida, segue o link:

    http://www.sommarskog.se/dyn-search.html

    Neste você irá encontrar informações sobre as diversas formas de utilização de SQL Dinâmico. Realmente, existem várias formas de fazer, mas cada uma destas tem alguma vantagem ou desvantagem sobre a outra.

    A forma que realmente achei mais interessante, é a utilização da "sp_executesql". Onde você pode passar exatamente qual query quer realizar, parâmetros que serão usados e valores para parâmetros.

    Bem, espero ter cooperado.

    Abs.

    quinta-feira, 5 de outubro de 2006 21:30