È meglio passare inserti di grandi dimensioni a SQL Server come parametro con valori di tabella o come istruzione di inserimento stringa?

Question

Sto scrivendo un'applicazione .NET che scrive dati su SQL Server 2008r2. Ho due opzioni per inserire i dati, o posso creare una dichiarazione di inserimento stringa di grandi dimensioni e inviarlo come comando di testo, oppure posso raccogliere i dati in un DataTable .NET e passarlo come parametro valutato a livello di tabella. Quali sono i vantaggi e i costi di ciascun metodo?

(sto omettendo una buona dose di codice dal momento che sto solo chiedendo circa i relativi benefici, non la sintassi specifica)

esempio:

Opzione 1:

string insert = @"insert into MyTable (id, val) values 
     (1, 'a'),(2,'b'),(3,'c'),(4,'d');" 

Opzione 2 :

DataTable dt = new DataTable(); 
    dt.Columns.Add("id", typeof(int)); 
    dt.Columns.Add("val", typeof(string)); 
    .... 
    create procedure uspMyProc 
        @tt ttMyTableType readonly 
       as 
       begin 
        insert into TestTable1 (id, strValue) 
        select myId, myVal from @tt; 
       end" 

Grazie per qualsiasi aiuto.

Answer 1

Opzione 3: In primo luogo vorrei popolare la stored procedure inserto con pena la propria istruzione di inserimento di parametri e chiamarlo più volte in un ciclo dal codice C#:

Opzione 4: Se hai veramente lotti di righe da inserire, forse hai bisogno di guardare nello SqlBulkCopy class. Consuma DataTable, DataRow o IDataReader. È possibile effettuare una IDataReader da un elenco di oggetti che utilizzano un codice personalizzato, una domanda di questo genere viene chiesto qui:

Get an IDataReader from a typed List

---

direi che dipende.

Se si desidera passare molte righe di parametri in forma tabellare, per qualsiasi motivo, utilizzare un parametro con valori di tabella - questo è il motivo per cui è presente.

Ho visto l'Opzione 1: alcuni codici DAL generici avrebbero scritto un "batch" SQL di comandi da eseguire. Ha funzionato, ma non ha dato alcuna difesa contro gli attacchi di iniezione. SQL parametrizzato fa.

---

Detto questo, vorrei favorire chiamando lo sproc inserto volta per ogni riga da inserire dal codice - le chiamate sarà completamente parametrizzato e le prestazioni va bene. Se le prestazioni diventano un problema, gradirei l'opzione 4.

Answer 2

Quanto è grande? Se è enorme, niente batte SqlBulkCopy. Ho effettivamente trovato le prestazioni TVP deludenti. Per il riutilizzo del piano di query, sono un fan delle dichiarazioni parametriche e di riutilizzo massiccio. Dapper può aiutare in questo modo, consentendo di passare un elenco di oggetti a una query: aggiungerà quindi i parametri nominati per oggetto in base al nome del membro, a molte migliaia di operazioni al secondo. Ad esempio:

conn.Execute(
    "insert foo (Id,Name) values (@Id,@Name)", 
    listOfObjects); 

Ciò scorrere la lista e utilizzare .Id e .Name da ogni oggetto a sua volta per eseguire la query.

Answer 3

Valori è limitata a 1000

e valori sembra avere alcune prestazioni emette

Insert Performance Issues With Multiple Values

Io uso TVP per l'inserimento di migliaia di righe e funziona benissimo per me. Uso una raccolta di elenchi come sorgente TVP poiché DataTable ha un sovraccarico. Inserisci le righe ordinate dal PK se puoi.

Con ciò detto ho intenzione di provare la risposta di Marc Gravell.

JNK ha una sfiducia generale nei confronti di TVP.