Non LINQ To SQL fornire tempi di risposta più veloce rispetto all'utilizzo di ado.net e oledb?

Question

LINQ semplifica la programmazione di database senza dubbio, ma ha un lato negativo?Inline SQL richiede per comunicare con il database in un certo modo, che apre il database per iniezioni.Inline SQL deve anche essere sintassi-controllato, hanno un piano costruito, e quindi eseguito, che prende preziosi cicli.Le Stored procedure sono stati anche una solida standard in grande database di programmazione dell'applicazione.Molti programmatori so usare un livello di dati che semplifica lo sviluppo, tuttavia, non nella misura in LINQ fa.È tempo di abbandonare la SP e andare LINQ?

Answer 1

LINQ to SQL in realtà presenta alcuni allarmanti problemi di prestazioni del database.In sostanza, si crea più piani di esecuzione in base alla lunghezza del parametro che si sta utilizzando.Ho postato su un po ' indietro sul mio blog LINQ to SQL può causare problemi di prestazioni.

Ora, è quella di dire che LINQ non ha un luogo?Difficilmente.LINQ ha sicuramente un posto nel toolkit di sviluppo, proprio come stored procedure.Infine, si desidera utilizzare le stored procedure in cui le prestazioni sono assolutamente necessari e utilizzare un ORM in qualsiasi altra situazione.

Come lontano come in linea di SQL va, ci sono modi per eseguire inline SQL in modo che il piano è costruito solo una volta e non è mai ricompilato.La maggior parte degli Orm dovrebbe prendere cura di questo aspetto di regolare le prestazioni e l'utilizzo di questi metodi è di solito il modo più sicuro per eseguire SQL poiché costringe a usare le query con parametri.

Come la maggior parte delle soluzioni di database, la risposta giusta dipende dal problema che si sta tentando di risolvere.Se si favorisce la velocità di sviluppo su database/prestazioni delle applicazioni, quindi utilizzando LINQ o altro DAL/ORM strumento è il modo migliore per andare.Se si favoriscono le prestazioni oltre la facilità di sviluppo, quindi l'utilizzo di stored procedure e puro set di dati sta per essere la vostra scommessa migliore.LLBLGen fornisce anche una LINQ to LLBLGen layer, in modo da utilizzare LINQ to query LLBLGen oggetti e hanno LLBLGen effettivamente gestire edificio vostre domande e per evitare alcune delle cadute di LINQ.

Answer 2

La tua premessa è sbagliata..

Inline SQL richiede per comunicare con il database in un certo modo, che apre il database per iniezioni.

No non è così.Hard-codifica inseriti dall'utente i valori in un'istruzione SQL, ma si può fare anche con store procedure.

La parametrizzazione di query di protezione contro gli attacchi di iniezione, ma inline SQL può essere parametrizzata con la stessa facilità di stored procedure.

Inline SQL deve anche essere sintassi-controllato, hanno un piano di costruzione, e quindi eseguito.

Tutti Sql (SPs e inline) deve essere sintassi-controllato e hanno un piano costruito su di loro prima chiamata.Successivamente, il testo esatto della richiesta & il piano di esecuzione vengono memorizzati nella cache.Se un'altra richiesta, con lo stesso identico testo (non contando i parametri) è ricevuto, il piano di esecuzione nella cache viene utilizzata.

Così, se è rigido codice di valori in inline SQL, il testo non corrispondono, e si ri-analizzare la query.Tuttavia, se si utilizza parametri, il testo della query abbinare, e si otterrà un cache hit.In questo caso, non importa se la query in linea di SQL o di un SP.

In altre parole, l'unico problema in linea di SQL è che è facile fare qualcosa che lento e insicuro.Ma facendo inline SQL veloce & sicuro non è più il lavoro che l'utilizzo di un SP.

Il che ci porta a LINQ, che sempre mediante parametri, anche se è difficile-codice i valori in LINQ istruzione, rendendo "veloce & sicuro" in linea di SQL banale.

LINQ hanno anche il vantaggio di SPs di avere tutto il codice in un punto, invece, disseminate su due macchine diverse.

Answer 3

Se siete interessati a benchmarking, Rico Mariani ha una eccellente 5-parte studio che copre le differenze qualitative e quantitative.

Egli può essere un MS ragazzo, ma è conosciuto come prestazioni dado - i suoi parametri di riferimento sono approfondite e ben pensato.

Answer 4

Questa è una prova da Massimiliano Beller.Secondo lui, LINQ è molto molto più lento.Leggere il suo studio completo

Answer 5

Solo pensare di cambiare una delle colonne nome - di modificare l' (n)SPs e (x)Viste.

Fare tutto ciò che è costoso sul database (così come la ricerca , l'ordinamento, ecc..) e non ti accorgi di un problema.

Inoltre, se si desidera visualizzare una griglia di grandi dimensioni senza paging ...quindi utilizzare un set di dati che è più veloce.

StackOverflow utilizza anche linq2sql - c'è un problema :) ?

Usare un ORM - è il modo per andare sulla maggior parte delle applicazioni.

PS:inoltre, sulla micro parametri di riferimento - come ..selezioniamo 10.000 righe con un ORM, NON FARLO.Non perché usare un ORM.Se si desidera selezionare 10.000 righe di utilizzare ADO.

Answer 6

Dipende da cosa stai facendo.LINQ sta per essere meno efficiente a dati effettivi/insieme di manipolazione di un vero e proprio database.Ma si risparmia un sacco di non avere la connessione al database in rete.

Se il database si trova sulla stessa macchina o è formalmente 'ben collegato', probabilmente stai meglio utilizzando di esso.

Ma se stai ricevendo indietro di un ampio set di risultati da un db remoto che potrebbe significare un notevole tempo di trasmissione, o se si tratta davvero di pochi query che non giustificare l'overhead, LINQ probabilmente sarebbe meglio.

Answer 7

A causa della struttura di LINQ to SQL, non c'è alcun modo in cui può essere più veloce di utilizzo di materie prime di SQL, sia proprio ben formato query o una stored procedure.Cosa LINQ si compra non è la velocità ma il tipo di sicurezza e di organizzazione;in breve, la maggior parte dei benefici che Orm generalmente concede.

LINQ to SQL non è questione di velocità, riguarda la costruzione di un più gestibile software di sistema.Si parla di tutte le cose di un Software dedicato, Ingegneri e degli Architetti in cura circa, roba come accoppiamento e la stratificazione

Questo non per dire che non si può costruire davvero non gestibile codice con LINQ-nessuno è mantenere il tiro da te in piedi ma tu, ma fatto correttamente, LINQ può aiutare immensamente.Non sto dicendo LINQ è un proiettile d'argento, tuttavia.Ha una serie di problemi che rendono difficile l'utilizzo in molte enterprise situazioni-che è il motivo per cui MS offre Entity Framework (ADO.NET 3.0).Naturalmente, anche questo non è perfetto, data la recente EF Voto di Fiducia.

È LINQ to SQL o anche EF meglio di raw SQL?Direi un clamoroso Hells Sì.Ci sono altre soluzioni che potrebbero funzionare meglio?Forse.