LINQ para SQL vs procedimentos armazenados? [fechadas]

Dei uma olhada na publicação "Guia para iniciantes em LINQ", aqui no StackOverflow ( Guia para iniciantes em LINQ ), mas tive uma pergunta de acompanhamento:

Estamos prestes a acelerar um novo projeto em que quase todas as operações de nosso banco de dados serão recuperações de dados bastante simples (há outro segmento do projeto que já grava os dados). A maioria dos nossos outros projetos até esse momento faz uso de procedimentos armazenados para essas coisas. No entanto, eu gostaria de aproveitar o LINQ-to-SQL se fizer mais sentido.

Portanto, a questão é a seguinte: para recuperações simples de dados, qual abordagem é melhor, LINQ-to-SQL ou procs armazenados? Algum profissional ou contra específico?

Obrigado.

Algumas vantagens do LINQ sobre sprocs:

1. Segurança de tipo : acho que todos entendemos isso.
2. Abstração : isso é especialmente verdade com o LINQ-to-Entities . Essa abstração também permite que a estrutura adicione aprimoramentos adicionais dos quais você pode facilmente tirar proveito. O PLINQ é um exemplo de adição de suporte multi-threading ao LINQ. As alterações de código são mínimas para adicionar esse suporte. Seria MUITO mais difícil fazer esse código de acesso a dados que simplesmente chama sprocs.
3. Suporte para depuração : eu posso usar qualquer depurador .NET para depurar as consultas. Com sprocs, você não pode depurar facilmente o SQL e essa experiência está amplamente ligada ao fornecedor do banco de dados (o MS SQL Server fornece um analisador de consultas, mas geralmente isso não é suficiente).
4. Independente do fornecedor : o LINQ funciona com muitos bancos de dados e o número de bancos de dados suportados só aumentará. Os sprocs nem sempre são portáteis entre os bancos de dados, devido à variação da sintaxe ou do suporte a recursos (se o banco de dados suportar sprocs).
5. Implantação : outros já mencionaram isso, mas é mais fácil implantar um único assembly do que implantar um conjunto de sprocs. Isso também está relacionado com o # 4.
6. Mais fácil : você não precisa aprender T-SQL para acessar dados, nem aprender a API de acesso a dados (por exemplo, ADO.NET) necessária para chamar os sprocs. Isso está relacionado aos itens 3 e 4.

Algumas desvantagens do LINQ vs sprocs:

1. Tráfego de rede : os sprocs precisam apenas serializar o nome do sproc e os dados do argumento pela conexão enquanto o LINQ envia a consulta inteira. Isso pode ficar muito ruim se as consultas forem muito complexas. No entanto, a abstração do LINQ permite que a Microsoft melhore isso com o tempo.
2. Menos flexível : os Sprocs podem aproveitar ao máximo o conjunto de recursos de um banco de dados. O LINQ tende a ser mais genérico em seu suporte. Isso é comum em qualquer tipo de abstração de linguagem (por exemplo, C # vs assembler).
3. Recompilando : Se você precisar fazer alterações na maneira como acessa os dados, é necessário recompilar, versão e reimplementar seu assembly. Às vezes, os Sprocs permitem que um DBA ajuste a rotina de acesso a dados sem a necessidade de reimplementar nada.

Segurança e gerenciabilidade também são algo sobre o qual as pessoas discutem.

1. Segurança : por exemplo, você pode proteger seus dados confidenciais restringindo o acesso diretamente às tabelas e colocando ACLs nos sprocs. Com o LINQ, no entanto, você ainda pode restringir o acesso direto a tabelas e, em vez disso, colocar ACLs em visualizações de tabela atualizáveis para obter um fim semelhante (supondo que seu banco de dados ofereça suporte a visualizações atualizáveis).
2. Gerenciamento : O uso de visualizações também oferece a vantagem de proteger seu aplicativo sem interrupções de alterações de esquema (como normalização de tabela). Você pode atualizar a exibição sem exigir que seu código de acesso a dados seja alterado.

Eu costumava ser um cara grande, mas estou começando a me inclinar para o LINQ como uma alternativa melhor em geral. Se há algumas áreas em que os sprocs são claramente melhores, provavelmente ainda escreverei um sproc, mas acessarei usando o LINQ. :)

Em geral, sou um defensor de colocar tudo em procedimentos armazenados, por todos os motivos pelos quais os DBAs vêm insistindo há anos. No caso do Linq, é verdade que não haverá diferença de desempenho com consultas CRUD simples.

Mas lembre-se de algumas coisas ao tomar essa decisão: usar qualquer ORM acopla você firmemente ao seu modelo de dados. Um DBA não tem liberdade para fazer alterações no modelo de dados sem forçar a alteração do código compilado. Com os procedimentos armazenados, é possível ocultar esse tipo de alteração até certo ponto, uma vez que a lista de parâmetros e o (s) conjunto (s) de resultados retornados de um procedimento representam seu contrato, e as entranhas podem ser alteradas, desde que o contrato ainda seja cumprido .

Além disso, se o Linq for usado para consultas mais complexas, o ajuste do banco de dados se tornará uma tarefa muito mais difícil. Quando um procedimento armazenado está lento, o DBA pode se concentrar totalmente no código isoladamente e tem muitas opções, apenas para que o contrato ainda seja cumprido quando ele terminar.

Eu já vi muitos casos em que problemas sérios em um aplicativo foram resolvidos por alterações no esquema e código nos procedimentos armazenados sem nenhuma alteração no código compilado implantado.

Talvez uma abordagem hybird seria legal com o Linq? O Linq pode, é claro, ser usado para chamar procedimentos armazenados.

Linq para Sql.

O servidor SQL armazenará em cache os planos de consulta, para que não haja ganho de desempenho para sprocs.

Suas instruções linq, por outro lado, serão logicamente parte e testadas com seu aplicativo. Os Sprocs estão sempre um pouco separados e são mais difíceis de manter e testar.

Se eu estivesse trabalhando em um novo aplicativo do zero agora, usaria o Linq, sem sprocs.

Para recuperação básica de dados, eu iria para o Linq sem hesitação.

Desde que mudei para o Linq, encontrei as seguintes vantagens:

1. Depurar meu DAL nunca foi tão fácil.
2. Compile a segurança do tempo quando o esquema for alterado sem preço.
3. A implantação é mais fácil porque tudo é compilado nas DLLs. Chega de gerenciar scripts de implantação.
4. Como o Linq pode suportar a consulta de qualquer coisa que implemente a interface IQueryable, você poderá usar a mesma sintaxe para consultar XML, Objects e qualquer outra fonte de dados sem precisar aprender uma nova sintaxe.

O LINQ inchará o cache do procedimento

Se um aplicativo estiver usando LINQ to SQL e as consultas envolverem o uso de seqüências de caracteres que podem ser altamente variáveis ​​em tamanho, o cache do procedimento do SQL Server ficará inchado com uma versão da consulta para cada comprimento de sequência possível. Por exemplo, considere as seguintes consultas muito simples criadas na tabela Person.AddressTypes no banco de dados AdventureWorks2008:

var p = 
    from n in x.AddressTypes 
    where n.Name == "Billing" 
    select n;

var p = 
    from n in x.AddressTypes 
    where n.Name == "Main Office" 
    select n;

Se essas duas consultas forem executadas, veremos duas entradas no cache do procedimento do SQL Server: uma ligada a um NVARCHAR (7) e a outra a um NVARCHAR (11). Agora imagine se houvesse centenas ou milhares de cadeias de entrada diferentes, todas com comprimentos diferentes. O cache do procedimento seria desnecessariamente preenchido com todos os tipos de planos diferentes para a mesma consulta exata.

Mais aqui: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

Eu acho que o argumento pro LINQ parece vir de pessoas que não têm histórico com o desenvolvimento de banco de dados (em geral).

Especialmente se você estiver usando um produto como o VS DB Pro ou o Team Suite, muitos dos argumentos apresentados aqui não se aplicam, por exemplo:

Mais difícil de manter e testar: o VS fornece verificação completa de sintaxe, estilo, verificação referencial e de restrição e muito mais. Ele também fornece recursos completos de teste de unidade e ferramentas de refatoração.

O LINQ torna o teste de unidade verdadeiro impossível, pois (em minha mente) ele falha no teste ACID.

A depuração é mais fácil no LINQ: Por quê? O VS permite a inserção completa do código gerenciado e a depuração regular dos SPs.

Compilado em uma única DLL em vez de scripts de implantação: Mais uma vez, o VS vem ao resgate, onde pode criar e implantar bancos de dados completos ou fazer alterações incrementais seguras aos dados.

Não precisa aprender TSQL com LINQ: Não, não precisa, mas precisa aprender LINQ - onde está o benefício?

Realmente não vejo isso como um benefício. Ser capaz de mudar algo isoladamente pode parecer bom em teoria, mas apenas porque as alterações cumprem um contrato não significa que está retornando os resultados corretos. Para poder determinar quais são os resultados corretos, você precisa do contexto e obtém esse contexto a partir do código de chamada.

Os aplicativos fracamente acoplados são o objetivo final de todos os bons programadores, pois eles realmente aumentam a flexibilidade. Ser capaz de mudar as coisas isoladamente é fantástico, e são seus testes de unidade que garantirão que ainda esteja retornando resultados apropriados.

Antes que todos fiquem chateados, acho que o LINQ tem seu lugar e tem um grande futuro. Mas, para aplicativos complexos e com uso intenso de dados, não acho que esteja pronto para substituir os procedimentos armazenados. Essa foi uma visão que eu ecoara por um MVP da TechEd este ano (eles permanecerão sem nome).

EDIT: O lado do LINQ to SQL Stored Procedure é algo sobre o qual ainda preciso ler mais - dependendo do que acho que posso alterar minha diatribe acima;)

LINQ é novo e tem seu lugar. O LINQ não foi inventado para substituir o procedimento armazenado.

Aqui vou me concentrar em alguns mitos de desempenho e CONS, apenas para "LINQ to SQL", é claro que posso estar totalmente errado ;-)

(1) As pessoas dizem que a declaração do LINQ pode "armazenar em cache" no SQL Server, para que não perca desempenho. Parcialmente verdade. "LINQ to SQL", na verdade, é o tempo de execução que traduz a sintaxe LINQ para a declaração TSQL. Portanto, do ponto de vista de desempenho, uma instrução SQL ADO.NET codificada não tem diferença que LINQ.

(2) Como exemplo, uma interface do usuário do serviço ao cliente possui uma função "transferência de conta". essa função em si pode atualizar 10 tabelas de banco de dados e retornar algumas mensagens de uma vez. Com o LINQ, você precisa criar um conjunto de instruções e enviá-las como um lote para o SQL Server. o desempenho deste lote LINQ-> TSQL traduzido dificilmente pode corresponder ao procedimento armazenado. Razão? porque você pode ajustar a menor unidade da instrução no procedimento Armazenado usando a ferramenta interna de criação de perfil e de execução SQL, não é possível fazer isso no LINQ.

O ponto é que, ao falar de uma única tabela de banco de dados e um pequeno conjunto de dados CRUD, o LINQ é tão rápido quanto SP. Mas, para uma lógica muito mais complicada, o procedimento armazenado é mais ajustável no desempenho.

(3) O "LINQ to SQL" facilmente cria iniciantes para apresentar problemas de desempenho. Qualquer pessoa sênior do TSQL pode dizer quando não usar o CURSOR (basicamente você não deve usar o CURSOR no TSQL na maioria dos casos). Com o LINQ e o encantador loop "foreach" com consulta, é muito fácil para um novato escrever esse código:

foreach(Customer c in query)
{
  c.Country = "Wonder Land";
}
ctx.SubmitChanges();

Você pode ver que esse código decente fácil é tão atraente. Mas, sob o capô, o tempo de execução .NET apenas traduz isso para um lote de atualização. Se houver apenas 500 linhas, este é um lote TSQL de 500 linhas; Se houver milhões de linhas, isso é um sucesso. Obviamente, usuários experientes não usarão esse caminho para fazer esse trabalho, mas o ponto é que é fácil cair dessa maneira.

O melhor código é nenhum código e, com os procedimentos armazenados, é necessário escrever pelo menos algum código no banco de dados e no aplicativo para chamá-lo, enquanto que com o LINQ to SQL ou o LINQ to Entities, você não precisa escrever nenhum código adicional. código além de qualquer outra consulta LINQ, além de instanciar um objeto de contexto.

O LINQ definitivamente tem seu lugar em bancos de dados específicos de aplicativos e em pequenas empresas.

Mas em uma grande empresa, onde os bancos de dados centrais servem como um hub de dados comuns para muitos aplicativos, precisamos de abstração. Precisamos gerenciar centralmente a segurança e mostrar históricos de acesso. Precisamos ser capazes de fazer uma análise de impacto: se eu fizer uma pequena alteração no modelo de dados para atender a uma nova necessidade de negócios, que consultas precisam ser alteradas e quais aplicativos precisam ser testados novamente? As visualizações e os procedimentos armazenados me dão isso. Se o LINQ puder fazer tudo isso e tornar nossos programadores mais produtivos, eu o agradeço - alguém tem experiência em usá-lo nesse tipo de ambiente?

Um DBA não tem liberdade para fazer alterações no modelo de dados sem forçar a alteração do código compilado. Com procedimentos armazenados, você pode ocultar esse tipo de alteração até certo ponto, uma vez que a lista de parâmetros e o (s) conjunto (s) de resultados retornados de um procedimento representam seu contrato, e as entranhas podem ser alteradas, desde que o contrato ainda seja cumprido .

Realmente não vejo isso como um benefício. Ser capaz de mudar algo isoladamente pode parecer bom em teoria, mas apenas porque as alterações cumprem um contrato não significa que está retornando os resultados corretos. Para poder determinar quais são os resultados corretos, você precisa do contexto e obtém esse contexto a partir do código de chamada.

IMHO, RAD = LINQ, RUP = Procs armazenados. Trabalhei para uma grande empresa da Fortune 500 por muitos anos, em vários níveis, incluindo gerenciamento e, francamente, nunca contrataria desenvolvedores de RUP para fazer o desenvolvimento de RAD. Eles são tão isolados que têm um conhecimento muito limitado do que fazer em outros níveis do processo. Com um ambiente em silos, faz sentido dar aos DBAs controle sobre os dados por meio de pontos de entrada muito específicos, porque outros francamente não sabem as melhores maneiras de realizar o gerenciamento de dados.

Mas as grandes empresas movem-se dolorosamente devagar na arena do desenvolvimento, e isso é extremamente caro. Há momentos em que você precisa se mover mais rápido para economizar tempo e dinheiro, e o LINQ fornece isso e muito mais.

Às vezes, acho que os DBAs são tendenciosos contra o LINQ porque sentem que isso ameaça a segurança no trabalho. Mas essa é a natureza da besta, senhoras e senhores.

Eu acho que você precisa ir com procs para qualquer coisa real.

A) Escrever toda a sua lógica no linq significa que seu banco de dados é menos útil porque apenas seu aplicativo pode consumi-lo.

B) Não estou convencido de que a modelagem de objetos seja melhor do que a modelagem relacional.

C) Testar e desenvolver um procedimento armazenado no SQL é muito mais rápido que um ciclo de edição de compilação em qualquer ambiente do Visual Studio. Você acabou de editar, F5 e apertar select e estará pronto para as corridas.

D) É mais fácil gerenciar e implantar procedimentos armazenados do que assemblies ... basta colocar o arquivo no servidor e pressionar F5 ...

E) O Linq to sql ainda grava códigos ruins quando você não espera.

Honestamente, acho que o melhor seria que o MS aumentasse o t-sql para que ele possa fazer uma projeção de junção implicitamente da maneira que o linq faz. O t-sql deve saber se você deseja executar order.lineitems.part, por exemplo.

O LINQ não proíbe o uso de procedimentos armazenados. Eu usei o modo misto com LINQ-SQL e LINQ-storedproc . Pessoalmente, fico feliz por não precisar escrever os procs armazenados ... pwet-tu.

Além disso, há o problema de possível reversão 2.0. Confie em mim, isso já aconteceu comigo algumas vezes, por isso tenho certeza de que aconteceu com outras pessoas.

Também concordo que a abstração é a melhor. Juntamente com o fato, o objetivo original de um ORM é fazer com que o RDBMS seja compatível com os conceitos de OO. No entanto, se tudo funcionou bem antes do LINQ, tendo que desviar um pouco dos conceitos de OO, em seguida, dane-se. Conceitos e realidade nem sempre se encaixam bem. Não há espaço para fanáticos militantes em TI.

Estou assumindo que você quer dizer Linq To Sql

Para qualquer comando CRUD, é fácil definir o desempenho de um procedimento armazenado versus qualquer tecnologia. Nesse caso, qualquer diferença entre os dois será insignificante. Tente criar um perfil para um objeto de campo 5 (tipos simples) com mais de 100.000 consultas selecionadas para descobrir se há uma diferença real.

Por outro lado, o verdadeiro rompedor de negociações será a questão de saber se você se sente confortável em colocar sua lógica de negócios no banco de dados ou não, o que é um argumento contra os procedimentos armazenados.

De acordo com os gurus, eu defino o LINQ como motocicleta e SP como carro. Se você quiser fazer uma viagem curta e tiver apenas passageiros pequenos (neste caso, 2), vá com o LINQ. Mas se você quer fazer uma jornada e ter banda grande, acho que você deve escolher SP.

Como conclusão, a escolha entre motocicleta ou carro depende da sua rota (comercial), duração (hora) e passageiros (dados).

Espero que ajude, posso estar errado. : D

Todas essas respostas que se inclinam para o LINQ referem-se principalmente à FACILIDADE DE DESENVOLVIMENTO, que está mais ou menos relacionada à má qualidade da codificação ou à preguiça na codificação. Eu sou assim apenas.

Algumas vantagens ou Linq, eu li aqui como, fácil de testar, fácil de depurar etc, mas estas não são onde estão conectadas à saída final ou ao usuário final. Isso sempre causa problemas ao usuário final no desempenho. Qual é o ponto de carregar muitas coisas na memória e aplicar filtros no uso do LINQ?

Novamente, TypeSafety, tenha cuidado para "ter cuidado para evitar a digitação incorreta", que novamente é de baixa qualidade que estamos tentando melhorar usando o linq. Mesmo nesse caso, se alguma coisa no banco de dados mudar, por exemplo, o tamanho da coluna String, o linq precisará ser recompilado e não seria seguro sem isso. Tentei.

Embora tenhamos encontrado boas, doces, interessantes etc, enquanto trabalhamos com o LINQ, ele tem a desvantagem de tornar o desenvolvedor preguiçoso :) e é provado 1000 vezes que é ruim (pode ser o pior) no desempenho em comparação com os procs armazenados.

Pare de ser preguiçoso. Estou tentando muito. :)

Para operações CRUD simples com um único ponto de acesso a dados, eu diria para o LINQ se você se sentir confortável com a sintaxe. Para uma lógica mais complicada, acho que os sprocs são mais eficientes em termos de desempenho se você é bom em T-SQL e em suas operações mais avançadas. Você também tem a ajuda do Tuning Advisor, do SQL Server Profiler, depurando suas consultas do SSMS etc.

O procedimento armazenado facilita o teste e você pode alterar a consulta sem tocar no código do aplicativo. Também com o linq, obter dados não significa que são os dados corretos. E testar a correção dos dados significa executar o aplicativo, mas com o procedimento armazenado é fácil testar sem tocar no aplicativo.

O resultado pode ser resumido como

LinqToSql para sites pequenos e protótipos. Isso realmente economiza tempo para a criação de protótipos.

Sps: Universal. Posso ajustar minhas consultas e sempre verificar ActualExecutionPlan / EstimatedExecutionPlan.

Create PROCEDURE userInfoProcedure
    -- Add the parameters for the stored procedure here
    @FirstName varchar,
    @LastName varchar
AS
BEGIN

    SET NOCOUNT ON;

    -- Insert statements for procedure here
    SELECT FirstName  , LastName,Age from UserInfo where FirstName=@FirstName
    and LastName=@FirstName
END
GO

http://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx

Tanto o LINQ quanto o SQL têm seus lugares. Ambos têm suas desvantagens e vantagens.

Às vezes, para recuperação de dados complexos, você pode precisar de procs armazenados. E às vezes você pode querer que outras pessoas usem seu processo armazenado no Sql Server Management Studio.

O Linq to Entities é ótimo para o desenvolvimento rápido de CRUD.

Claro que você pode criar um aplicativo usando apenas um ou outro. Ou você pode misturar. Tudo se resume às suas necessidades. Mas os procs armazenados SQL não desaparecerão tão cedo.