Question

I have a table which needs to be populated with quite a few rows, on the order of millions per hour.

Right now I have an application developed in C# using the entity framework and it does not support bulk copying. I have previously developed a solution which uses bulk copying and it was a massive performance improvement.

I have been copying the data to a staging table and then merging the staging table with the production table, in order to resolve UNIQUE constraint conflicts.

Now my question today is, should I be using a temporary table as a variable inside the stored procedure and do all of the merging and conflict resolution there? In the current solution, we do the bulk copy and then invoke a stored procedure which merges and empties the table.

What kind of performance effects would it have to use the temporary table?

Is it considered a bad practice at all to use the temporary table? If so, why?

Are there alternatives in MSSQL 2012 that would be neat to use to solve this problem?

Answer 1

should I be using a temporary table as a variable inside the stored
procedure and do all of the merging and conflict resolution there?

I think it’s better use temp table to avoid problems with concurrent execution of the stored procedure, for different instances of the procedure can try to read and modify the same rows.

What kind of performance effects would it have to use the temporary
table?

Temp tables (as well as table variables) are stored in tempdb so you can get a bottleneck there.

Is it considered a bad practice at all to use the temporary table?

No. But using them without necessity you do extra write and read operations because first you read data by some query, write it into temp table and than read data one more time.