T-SQL memorizzato procs ordini di grandezza più veloce di LINQ

3

In base alle risposte che ho visto sullo stackoverflow, le stored procedure (e in misura minore le funzioni db) tendono a presentare risultati migliori rispetto ai framework LINQ + ORM (ad esempio Entity Framework).

Voglio determinare se la differenza di prestazioni è sufficientemente ampia da giustificare un aumento dei tempi di sviluppo, presupponendo che ci vuole più tempo per scrivere operazioni di query equivalenti e ragionevolmente complesse in T-SQL vs LINQ.

In quali scenari c'è una differenza di ordine di grandezza (o almeno un fattore costante molto grande) nel tempo di esecuzione, tra un processo memorizzato ottimizzato per le prestazioni e una controparte LINQ ottimizzata per le prestazioni? O per le funzioni con valori scalari o di tabella rispetto all'equivalente LINQ?

Si spera che non sia troppo difficile capire che questa domanda segue le linee guida delle Domande frequenti . Non sta ponendo una domanda soggettiva come "che è meglio, T-SQL o LINQ?". Sta chiedendo alcuni scenari specifici (può fornire esempi astratti o concreti) dove c'è una differenza significativa nelle prestazioni. Se ciò non ha ancora senso per te, e pensi ancora che questa domanda non sia costruttiva e debba essere chiusa, ti preghiamo di lasciare una spiegazione sul perché, se possibile.

    
posta T. Webster 06.01.2012 - 07:31
fonte

3 risposte

6

Il mio suggerimento:
1. Sviluppo con LINQ per ottenere un prodotto sul mercato più velocemente.
2. Ottimizza le prestazioni dell'intero sistema utilizzando la cache e simili.
3. Ottimizza le prestazioni di quelle poche domande in cui è davvero importante.

Nell'ordine elencato.

    
risposta data 12.01.2012 - 15:55
fonte
1

Penso che stai facendo un'assunzione errata che ci vorrà più tempo per creare una stored procedure rispetto a una query LINQ equivalente. La velocità extra può essere un enorme vantaggio anche se qui è un articolo che parla di studi di Google e Amazon in cui l'aumento del tempo di caricamento inferiore a 0,5 secondi ha avuto un enorme impatto sulle entrate. Data la lunga vita della maggior parte delle applicazioni, sembra sciocco preoccuparsi di un paio di ore in più di tempo per lo sviluppatore per ciò che potrebbe funzionare in giorni di tempo non sprecati dagli utenti e / o aumenti significativi delle entrate. Un'altra cosa da considerare è che MS sta lasciando cadere L2S in favore di EF.

    
risposta data 12.01.2012 - 16:46
fonte
1

In which scenarios is there an order-of-magnitude (or at least a very large constant factor) difference in running time, between a performance-optimized stored proc and its equivalent, performance-optimized LINQ counterpart? Or for scalar- or table- valued functions vs. the LINQ equivalent?

1 - Quando la logica aziendale richiede di esaminare diverse righe di dati o una grande quantità di dati in generale prima di prendere una decisione o prima di calcolare un risultato, le stored procedure hanno il vantaggio di eseguire questa elaborazione sul server di database stesso e potrebbero prendere una decisione binaria o eseguire il calcolo sul server senza passare alcun dato commerciale al client. Ciò si traduce in una buona prestazione. Supponiamo che tu abbia una regola aziendale complessa che richiede l'esame di 3 tabelle prima di eseguire un inserimento. Se vuoi che il tuo strappo medio lo faccia, devi portare i dati tramite una query o più allo strappo medio, eseguire il codice C # (per esempio) e poi continuare con l'inserimento o generare un errore. Quando si implementa la stessa logica sul server, non è necessario passare alcun dato al client (eccetto il risultato).

2 - Le stored procedure vengono anche utilizzate nei trigger e questo è qualcosa per cui non è possibile utilizzare LINQ.

    
risposta data 11.02.2012 - 19:06
fonte

Leggi altre domande sui tag