LINQ-to-SQL vs stored procedure? [chiuso]

Ho dato un'occhiata al post "Guida per principianti a LINQ" qui su StackOverflow ( Guida per principianti a LINQ ), ma domanda di follow-up:

Stiamo per avviare un nuovo progetto in cui quasi tutte le operazioni del nostro database saranno recuperi di dati abbastanza semplici (c'è un altro segmento del progetto che già scrive i dati). La maggior parte dei nostri altri progetti fino ad ora fa uso di stored procedure per tali cose. Tuttavia, vorrei sfruttare LINQ-to-SQL se ha più senso.

Quindi, la domanda è questa: per semplici recuperi di dati, quale approccio è migliore, LINQ-to-SQL o proc memorizzati? Qualche pro o contro specifico?

Grazie.

Alcuni vantaggi di LINQ rispetto agli sprocs:

1. Tipo di sicurezza : penso che tutti lo capiamo.
2. Astrazione : questo è particolarmente vero con LINQ-to-Entities . Questa astrazione consente inoltre al framework di aggiungere ulteriori miglioramenti di cui puoi facilmente trarre vantaggio. PLINQ è un esempio di aggiunta del supporto multi-threading a LINQ. Le modifiche al codice sono minime per aggiungere questo supporto. Sarebbe MOLTO più difficile eseguire questo codice di accesso ai dati che chiama semplicemente sprocs.
3. Supporto per il debug : posso utilizzare qualsiasi debugger .NET per eseguire il debug delle query. Con sprocs, non è possibile eseguire facilmente il debug di SQL e tale esperienza è in gran parte legata al fornitore del database (MS SQL Server fornisce un analizzatore di query, ma spesso non è sufficiente).
4. Fornitore indipendente : LINQ funziona con molti database e il numero di database supportati non farà che aumentare. Gli sproc non sono sempre portabili tra i database, a causa della diversa sintassi o del supporto delle funzionalità (se il database supporta gli sprocs).
5. Distribuzione : altri lo hanno già menzionato, ma è più semplice distribuire un singolo assembly piuttosto che distribuire una serie di sprocs. Questo si collega anche con il n. 4.
6. Più facile : non devi imparare T-SQL per eseguire l'accesso ai dati, né devi imparare l'API di accesso ai dati (ad esempio ADO.NET) necessaria per chiamare gli sprocs. Questo è correlato a # 3 e # 4.

Alcuni svantaggi di LINQ vs sprocs:

1. Traffico di rete : gli sprocs devono solo serializzare i dati di nome sproc e argomento sul cavo mentre LINQ invia l'intera query. Questo può andare davvero male se le query sono molto complesse. Tuttavia, l'astrazione di LINQ consente a Microsoft di migliorare questo nel tempo.
2. Meno flessibile : Sprocs può sfruttare appieno il set di funzionalità di un database. LINQ tende ad essere più generico nel suo supporto. Questo è comune in qualsiasi tipo di astrazione linguistica (ad es. C # vs assemblatore).
3. Ricompilazione : se è necessario apportare modifiche al modo in cui si accede ai dati, è necessario ricompilare, versione e ridistribuire l'assembly. Gli sprocs possono talvolta consentire a un DBA di ottimizzare la routine di accesso ai dati senza la necessità di ridistribuire nulla.

Sicurezza e gestibilità sono qualcosa di cui anche la gente discute.

1. Sicurezza : ad esempio, è possibile proteggere i dati sensibili limitando l'accesso diretto alle tabelle e inserendo ACL negli sprocs. Con LINQ, però, è ancora possibile limitare l'accesso diretto ai tavoli e ACL invece messo sul tavolo aggiornabili viste per raggiungere un fine simile (supponendo vostri supporti di database viste aggiornabili).
2. Gestibilità : l'utilizzo delle viste offre anche il vantaggio di proteggere l'applicazione senza interruzioni dalle modifiche dello schema (come la normalizzazione della tabella). È possibile aggiornare la vista senza richiedere la modifica del codice di accesso ai dati.

Ero un grande sproc, ma sto iniziando a propendere verso LINQ come alternativa migliore in generale. Se ci sono alcune aree in cui gli sprocs sono chiaramente migliori, probabilmente scriverò comunque uno sproc ma accederò usando LINQ. :)

In genere sono un sostenitore di mettere tutto nelle procedure archiviate, per tutte le ragioni per cui i DBA sono in corso da anni. Nel caso di Linq, è vero che non ci saranno differenze di prestazioni con semplici query CRUD.

Ma tieni a mente alcune cose quando prendi questa decisione: usare qualsiasi ORM ti accoppia strettamente al tuo modello di dati. Un DBA non ha la libertà di apportare modifiche al modello di dati senza forzare la modifica del codice compilato. Con le stored procedure, è possibile nascondere questo tipo di modifiche in una certa misura, poiché l'elenco dei parametri e i set di risultati restituiti da una procedura rappresentano il suo contratto e le parti interne possono essere cambiate, purché il contratto sia ancora rispettato .

Inoltre, se Linq viene utilizzato per query più complesse, l'ottimizzazione del database diventa un'attività molto più difficile. Quando una procedura memorizzata sta funzionando lentamente, il DBA può concentrarsi totalmente sul codice in modo isolato e ha molte opzioni, solo in modo che il contratto sia ancora soddisfatto al termine.

Ho visto molti, molti casi in cui gravi problemi in un'applicazione sono stati risolti da modifiche allo schema e al codice nelle procedure memorizzate senza alcuna modifica al codice distribuito e compilato.

Forse un approccio hybird sarebbe carino con Linq? Naturalmente Linq può essere utilizzato per chiamare le procedure memorizzate.

Linq a Sql.

Il server SQL memorizzerà nella cache i piani di query, quindi non vi è alcun miglioramento delle prestazioni per gli sprocs.

Le tue dichiarazioni linq, d'altra parte, saranno logicamente parte e testate con la tua applicazione. Gli sprocs sono sempre un po 'separati e sono più difficili da mantenere e testare.

Se stavo lavorando su una nuova applicazione da zero in questo momento avrei semplicemente usato Linq, senza sprocs.

Per il recupero dei dati di base, sceglierei Linq senza esitazione.

Da quando mi sono trasferito a Linq ho trovato i seguenti vantaggi:

1. Il debug del mio DAL non è mai stato così facile.
2. Compilare la sicurezza del tempo quando le modifiche allo schema non hanno prezzo.
3. La distribuzione è più semplice perché tutto è compilato in DLL. Non più gestione degli script di distribuzione.
4. Poiché Linq può supportare l'interrogazione di tutto ciò che implementa l'interfaccia IQueryable, sarai in grado di utilizzare la stessa sintassi per interrogare XML, Oggetti e qualsiasi altra origine dati senza dover imparare una nuova sintassi

LINQ gonfia la cache delle procedure

Se un'applicazione utilizza LINQ to SQL e le query implicano l'uso di stringhe che possono avere una lunghezza molto variabile, la cache delle procedure di SQL Server diventerà gonfia con una versione della query per ogni possibile lunghezza della stringa. Ad esempio, prendere in considerazione le seguenti query molto semplici create nella tabella Person.AddressTypes nel database 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 vengono eseguite entrambe queste query, vedremo due voci nella cache delle procedure di SQL Server: una associata a una NVARCHAR (7) e l'altra a una NVARCHAR (11). Ora immagina se ci fossero centinaia o migliaia di stringhe di input diverse, tutte con lunghezze diverse. La cache delle procedure verrebbe riempita inutilmente di tutti i tipi di piani diversi per la stessa identica query.

Altro qui: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

Penso che l'argomento pro LINQ sembra provenire da persone che non hanno una storia con lo sviluppo del database (in generale).

Soprattutto se si utilizza un prodotto come VS DB Pro o Team Suite, molti degli argomenti qui riportati non si applicano, ad esempio:

Più difficile da mantenere e testare: VS fornisce il controllo completo della sintassi, il controllo dello stile, il controllo referenziale e dei vincoli e altro ancora. Fornisce inoltre funzionalità complete di test unitari e strumenti di refactoring.

LINQ rende impossibile il vero test unitario poiché (nella mia mente) non supera il test ACID.

Il debug è più semplice in LINQ: perché? VS consente il pieno passaggio dal codice gestito e il debug regolare degli SP.

Compilato in una singola DLL anziché in script di distribuzione: Ancora una volta, VS viene in soccorso dove può creare e distribuire database completi o apportare modifiche incrementali sicure per i dati.

Non devi imparare TSQL con LINQ: No, non devi, ma devi imparare LINQ - dov'è il vantaggio?

Davvero non lo vedo come un vantaggio. Essere in grado di cambiare qualcosa in isolamento potrebbe sembrare buono in teoria, ma solo perché i cambiamenti soddisfano un contratto non significa che sta restituendo i risultati corretti. Per essere in grado di determinare quali sono i risultati corretti, è necessario contesto e si ottiene quel contesto dal codice chiamante.

Ehm, le app debolmente accoppiate sono l'obiettivo finale di tutti i bravi programmatori poiché aumentano davvero la flessibilità. Essere in grado di cambiare le cose in isolamento è fantastico, ed è il tuo test unitario che assicurerà che stia ancora restituendo risultati adeguati.

Prima che vi arrabbiate, penso che LINQ abbia il suo posto e abbia un grande futuro. Ma per applicazioni complesse ad alta intensità di dati non penso che sia pronto a sostituire le procedure memorizzate. Questa è stata una visione che ho fatto eco da un MVP alla TechEd quest'anno (rimarranno senza nome).

EDIT: il lato delle procedure memorizzate LINQ to SQL è qualcosa su cui ho ancora bisogno di leggere di più - a seconda di ciò che trovo potrei modificare la mia precedente diatriba;)

LINQ è nuovo e ha il suo posto. LINQ non è stato inventato per sostituire la procedura memorizzata.

Qui mi concentrerò su alcuni miti prestazionali e CONS, solo per "LINQ to SQL", ovviamente potrei sbagliarmi totalmente ;-)

(1) Le persone dicono che lo statment LINQ può "cache" nel server SQL, quindi non perde le prestazioni. Parzialmente vero. "LINQ to SQL" è in realtà il runtime che traduce la sintassi LINQ in istruzioni TSQL. Quindi, dal punto di vista delle prestazioni, un'istruzione SQL ADO.NET codificata non ha alcuna differenza rispetto a LINQ.

(2) Dato un esempio, un'interfaccia utente del servizio clienti ha una funzione "trasferimento account". questa stessa funzione potrebbe aggiornare 10 tabelle DB e restituire alcuni messaggi in un colpo solo. Con LINQ, è necessario creare una serie di istruzioni e inviarle come un batch a SQL Server. le prestazioni di questo batch LINQ-> TSQL tradotto difficilmente possono eguagliare la procedura memorizzata. Motivo? poiché è possibile modificare l'unità più piccola dell'istruzione in Stored procedure utilizzando il profiler SQL incorporato e lo strumento del piano di esecuzione, non è possibile farlo in LINQ.

Il punto è che quando si parla di una singola tabella DB e un piccolo set di dati CRUD, LINQ è veloce come SP. Ma per una logica molto più complicata, la procedura memorizzata è più ottimizzabile in termini di prestazioni.

(3) "LINQ to SQL" rende facilmente i neofiti introdurre i maiali delle prestazioni. Qualsiasi tipo TSQL senior può dirti quando non usare CURSOR (in pratica non dovresti usare CURSOR in TSQL nella maggior parte dei casi). Con LINQ e l'affascinante ciclo "foreach" con query, è così facile per un principiante scrivere questo codice:

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

Puoi vedere che questo semplice codice decente è così attraente. Ma sotto il cofano, il runtime .NET lo traduce in un batch di aggiornamento. Se ci sono solo 500 righe, questo è un batch TSQL a 500 righe; Se ci sono milioni di linee, questo è un successo. Naturalmente, l'utente esperto non utilizzerà questo modo per fare questo lavoro, ma il punto è che è così facile cadere in questo modo.

Il codice migliore è nessun codice e con le procedure memorizzate devi scrivere almeno un po 'di codice nel database e il codice nell'applicazione per chiamarlo, mentre con LINQ to SQL o LINQ to Entities, non devi scrivere alcun ulteriore oltre ogni altra query LINQ oltre all'istanza di un oggetto di contesto.

LINQ ha sicuramente il suo posto nei database specifici dell'applicazione e nelle piccole imprese.

Ma in una grande impresa, in cui i database centrali fungono da hub di dati comuni per molte applicazioni, abbiamo bisogno di astrazione. Dobbiamo gestire centralmente la sicurezza e mostrare la cronologia degli accessi. Dobbiamo essere in grado di eseguire analisi di impatto: se apporto una piccola modifica al modello di dati per soddisfare una nuova esigenza aziendale, quali query devono essere modificate e quali applicazioni devono essere testate nuovamente? Visualizzazioni e procedure memorizzate mi danno questo. Se LINQ può fare tutto ciò e rendere i nostri programmatori più produttivi, lo accolgo con favore: qualcuno ha esperienza nell'usarlo in questo tipo di ambiente?

Un DBA non ha la libertà di apportare modifiche al modello di dati senza forzare la modifica del codice compilato. Con le stored procedure, è possibile nascondere questo tipo di modifiche in una certa misura, poiché l'elenco dei parametri e i set di risultati restituiti da una procedura rappresentano il suo contratto e le parti interne possono essere cambiate, purché il contratto sia ancora rispettato .

Davvero non lo vedo come un vantaggio. Essere in grado di cambiare qualcosa in isolamento potrebbe sembrare buono in teoria, ma solo perché i cambiamenti soddisfano un contratto non significa che sta restituendo i risultati corretti. Per essere in grado di determinare quali sono i risultati corretti, è necessario contesto e si ottiene quel contesto dal codice chiamante.

IMHO, RAD = LINQ, RUP = Procs memorizzati. Ho lavorato per una grande azienda Fortune 500 per molti anni, a molti livelli, compresa la gestione, e francamente, non avrei mai assunto gli sviluppatori RUP per fare lo sviluppo RAD. Sono così insidiosi che hanno una conoscenza molto limitata di cosa fare ad altri livelli del processo. Con un ambiente silenzioso, ha senso dare ai DBA il controllo sui dati attraverso punti di ingresso molto specifici, perché altri francamente non conoscono i modi migliori per realizzare la gestione dei dati.

Ma le grandi imprese si muovono dolorosamente lente nell'arena dello sviluppo, e questo è estremamente costoso. Ci sono momenti in cui devi muoverti più velocemente per risparmiare tempo e denaro, e LINQ offre questo e molto altro.

A volte penso che i DBA siano di parte nei confronti di LINQ perché ritengono che minacci la sicurezza del loro lavoro. Ma questa è la natura della bestia, signore e signori.

Penso che devi andare con i proc per qualsiasi cosa di reale.

A) Scrivere tutta la logica in linq significa che il database è meno utile perché solo l'applicazione può utilizzarlo.

B) Non sono convinto che la modellazione di oggetti sia comunque migliore della modellazione relazionale.

C) Testare e sviluppare una procedura memorizzata in SQL è molto più veloce di un ciclo di modifica della compilazione in qualsiasi ambiente di Visual Studio. Basta modificare, F5 e premere select e si parte per le gare.

D) È più facile gestire e distribuire le procedure memorizzate rispetto agli assiemi .. basta inserire il file sul server e premere F5 ...

E) Linq in sql scrive ancora codice scadente a volte quando non te lo aspetti.

Onestamente, penso che l'ultima cosa sarebbe che MS aumentasse t-sql in modo che possa fare una proiezione di join implicitamente come fa Linq. t-sql dovrebbe sapere se volevi fare order.lineitems.part, per esempio.

LINQ non proibisce l'uso di stored procedure. Ho usato la modalità mista con LINQ-SQL e LINQ-storedproc . Personalmente, sono contento di non dover scrivere i proc memorizzati .... pwet-tu.

Inoltre, esiste il problema del possibile rollback 2.0. Fidati di me, mi è successo un paio di volte, quindi sono sicuro che sia successo ad altri.

Concordo anche sul fatto che l'astrazione sia la migliore. Insieme al fatto, lo scopo originale di un ORM è far corrispondere bene RDBMS ai concetti OO. Tuttavia, se tutto ha funzionato bene prima di LINQ dovendo deviare un po 'dai concetti di OO, allora fanculo. Concetti e realtà non sempre si adattano bene insieme. Non c'è spazio per i fanatici militanti dell'IT.

Suppongo che intendi Linq To Sql

Per qualsiasi comando CRUD è facile profilare le prestazioni di una procedura memorizzata rispetto a qualsiasi tecnologia. In questo caso qualsiasi differenza tra i due sarà trascurabile. Prova a profilare per un oggetto campo 5 (tipi semplici) oltre 100.000 query selezionate per scoprire se c'è una vera differenza.

D'altra parte, il vero affare sarà la domanda se ti senti a tuo agio nel mettere la tua logica aziendale nel tuo database o meno, che è un argomento contro le procedure memorizzate.

Secondo i guru, definisco LINQ come moto e SP come auto. Se vuoi fare un breve viaggio e avere solo passeggeri piccoli (in questo caso 2), vai con garbo con LINQ. Ma se vuoi fare un viaggio e avere una grande band, penso che dovresti scegliere SP.

In conclusione, la scelta tra moto o auto dipende dal percorso (attività), dalla durata (tempo) e dai passeggeri (dati).

Spero che sia d'aiuto, potrei sbagliarmi. : D

Tutte queste risposte che si appoggiano a LINQ parlano principalmente di FACILITÀ DI SVILUPPO che è più o meno connessa alla scarsa qualità della codifica o alla pigrizia nella codifica. Sono solo così.

Alcuni vantaggi o Linq, ho letto qui come, facili da testare, facili da eseguire il debug ecc., Ma questi non sono collegati all'output finale o all'utente finale. Ciò causa sempre problemi all'utente finale in termini di prestazioni. Qual è il punto di caricare molte cose in memoria e quindi applicare i filtri nell'uso di LINQ?

Ancora una volta TypeSafety, avverte che "stiamo attenti a evitare la tipografia errata", che di nuovo di scarsa qualità stiamo cercando di migliorare utilizzando Linq. Anche in quel caso, se qualcosa nel database cambia, ad esempio la dimensione della colonna String, allora linq deve essere ricompilato e senza questo non sarebbe un errore di battitura. Ci ho provato.

Anche se abbiamo scoperto che è buono, dolce, interessante ecc. Mentre si lavora con LINQ, ha lo svantaggio di rendere pigro lo sviluppatore :) ed è dimostrato 1000 volte che è cattivo (potrebbe essere il peggiore) in termini di prestazioni rispetto a Stored Procs.

Smetti di essere pigro. Ci sto provando duramente. :)

Per semplici operazioni CRUD con un singolo punto di accesso ai dati, direi di utilizzare LINQ se ti senti a tuo agio con la sintassi. Per una logica più complicata penso che gli sprocs siano più efficaci dal punto di vista delle prestazioni se sei bravo con T-SQL e le sue operazioni più avanzate. Hai anche l'aiuto di Tuning Advisor, SQL Server Profiler, debug delle tue query da SSMS ecc.

La procedura memorizzata semplifica i test e puoi modificare la query senza toccare il codice dell'applicazione. Anche con linq, ottenere un dato non significa che sia il dato giusto. E testare la correttezza dei dati significa eseguire l'applicazione ma con la procedura memorizzata è facile testare senza toccare l'applicazione.

Il risultato può essere sintetizzato come

LinqToSql per piccoli siti e prototipi. Fa davvero risparmiare tempo per il prototipo.

Sps: universale. Sono in grado di ottimizzare le mie query e controllare sempre ActualExecutionPlan / StimatedExecutionPlan.

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

Sia LINQ che SQL hanno il loro posto. Entrambi hanno i loro svantaggi e vantaggi.

A volte per il recupero di dati complessi potrebbe essere necessario un processo memorizzato. E a volte potresti volere che altre persone usino il tuo proc memorizzato in Sql Server Management Studio.

Linq to Entities è ottimo per uno sviluppo CRUD veloce.

Sicuro che puoi creare un'app usando solo l'una o l'altra. Oppure puoi mescolarlo. Tutto dipende dalle tue esigenze. Ma i proc memorizzati SQL non scompariranno presto.