none
Linq com StoredProcedure RRS feed

  • Pergunta

  • Será que vale a pena utlizar sp com Linq? Isso não deixaria o código dependente do db?

    Att,

    Ricardo

    Ricardo Novais
    segunda-feira, 29 de junho de 2009 02:15

Todas as Respostas

  • Bem, depende....

    Tem casos onde ainda é melhor vc manter um SP rodando em um servidor SQL de alta capacidade do que rodar esse mesmo processo num terminal com o LINQ, principalmente no caso de pagina ASP, ja imaginou 1000 usuarios rodando um calculo de 2 seg. no IIS ? vc gera um pool de resposta de 2000 segundos dependendo da forma q for feito....

    Nesses casos SP ainda é uma soluçao preferencial...

    Sobre portalibidade... não é tão grave assim... teoricamente praticamente todos os SGBDs do mercado tem suporte a SPs, como o linq 2 enteties sabe como fazer a chamada em cada um deles, tendo os mesmos parametros, na mesma tipagem e o mesmo tipo de retorno.... é so uma questao de reescrever a procedure para o script da base a ser utilizada...

    Ja converti sistemas de Oracle para SQL Server, para Sysbase... enfim... aqueles q era baseados em SP eram muito mais tranquilos de migrar que os que nao usavam...
    Se não funciona de um jeito, tente de outro totalmente diferente ^_^
    segunda-feira, 29 de junho de 2009 03:02
    Moderador
  • Eu discordo, pois, o Linq gera o select que será executado no banco, ele vai até o banco, processa e retorna para o método. Na internet há várias matérias sobre a performance do Linq.

    O grande lance é na hora de montar a instrução Linq.


    Se você fizer assim: var teste = (from t in db.Teste select t) where (p => p.ID < 5000);
    é como se vc fizer Select * from teste

    vai ver que o que é gerado é um select de todos os registros, trazer para memória e aí sim seria ruim.

    Mas se você fizer:
    var teste = (from t in db.Teste where t.ID < 5000 select new {t.ID, t.Nome})
    select ID, Nome from teste where ID < 5000


    A transação é feita apenas para o que vc precisa e ele executará um reader.... não há o que seja mais rápido....

    Fizemos testes na instituição financeira que trabalho e Linq demonstrou MUITO mais performático.......

    Minato alexandre.minato@hotmail.com
    quinta-feira, 6 de agosto de 2009 02:58
  • Alexandre....

    Concordo com o que vc expos... mas 

     tem como criar um loop no linq que roda 100% no servidor ?

    nos caso que usam cursor ?  condicoes.... tipo percorrer uma tabela e dependendo do valor de um determinado campo vc exclui o registro ou consulta outra tabela... ou faz um calculo... enfim... acredito q montar um Procedure para fazer algo que vc apenas com um select... nao faz sentindo usar procedure... mas e nos caso mais complexos... ? 

    Tenho um sistema LINQ que faz uma consulta de template Biometricos em uma base com mais de 6.000.000 de registros.... e um SP que faz a mesma coisa.... a SP eh 10x mais rapida.... mesmo tendo q acessar um componente activeX para fazer a comparacao biometrica...
    quinta-feira, 6 de agosto de 2009 03:49
    Moderador
  • Rui,

    Qual a frequência de atualização?
    Motivo: Se a atualização for frequente (por exemplo, precisa consultar a informação de segundo em segundo, você poderia colocar as informações em Cache e utilizar um TimeStamp para controlar as alterações).

    Quantos servidores você utiliza?
    Motivo: Suponha que você tenha 5 servidores. Você terá que trazer para memória em todos os servidores em virtude do balanceamento.

    Hoje trabalho em uma instituição financeira e posso assegurar que o Linq utilizado de forma correta é MUITO mais rápido.

    Se trouxer as informações necessárias para memória e utiliza-la de forma correta (por exemplo, seria um erro utilizar Where, FindAll para buscar uma informação chave, ou seja que exista apenas um registro ao inves de utilizar o FirstOrDefault, que seria o correto).

    Dê um pouco mais de detalhes para podermos ajuda-lo


    Minato alexandre.minato@hotmail.com
    sexta-feira, 7 de agosto de 2009 01:46
  • Alexandre... vc nao entendeu a questao.... o caso nao eh fazer consulta de dados aqui...

    Eu trabalho para o Governo do Estado de São Paulo... mais exatamente com os sistemas do Detran...

    O que to falando é de casos onde sao necessarias os uso de Cursores.... nao vale a pena vc carregar uma tabela gigantesca na memoria do aplicativo com o Linq para poder fazer um loop para executar outras consultas para no final retorna apenas meia duzia de linhas.... nesses casos o melhor é criar o laço dentro do banco de dados e trafegar apenas os dados do resultado dessa operaçao...

    To falando pq uma consulta onde tinha que identificar todos os canditatos a condutores que estavam utilizando um mesmo template biometrico... um sistema em Linq rodando balanceadamente em 6 servidores retorna a lista de provavel canditatos fraudulentos no ultimo mes em cerca de 70h.... criando a mesma logica em uma SP dentro de un unico servidor esse tempo caiu para 10h....

    Alias, tmb ja trabalhei com instituiçoes financeiras... e tem casos que trabalha no servidor ainda é superior.... mas eh o que eu disse.... se é algo q vc pode resolver com apenas uma unica query.. nao tem nem sentido fazer uma SP, estamos falando nos casos em que as SP sao fatores cruciais... se elas valem a pena ou nao de se usar devido a portabilidade de banco de dados do Linq.

    Essa por sinal foi a pergunta, e volto a afirmas que nao perde a portabilidade uma vez q a chamada para execuçao da procedure eh controlada pelo provider de acesso ao banco e portanto basta apenas adaptar a sp ao banco q nao vai prescisar fazer alteraçao no codigo Linq.... essa era a pergunta e essa foi a minha resposta.... simples assim....



    What would Brian Boitano do ?
    sexta-feira, 7 de agosto de 2009 03:32
    Moderador