January 18, 2013 at 2:08 pm
i also found that performance of MERGE is a bit worse than just INSERT/UPDATE - with indexes in place - it is not a huge difference but still noticeable.
Also it is hard to debug/troubleshoot MERGE statements - with INSERT/UPDATEs you can just select the SELECT part with joins and WHERE clause and run it to see results and play with them till you are ready to do actual inserts/updates.
With Merge statement, you would have to cut out the code from it and run on a side or use output clause which you have to type or uncomment.
One pain at least in 2008, that you cannot use results on OUTPUT clause outside of the MERGE (as a inner query) - you can only insert results to a table variable which you need to define and create first.
So after some first excitements our team is back on using old good UPSERTs.
August 28, 2013 at 9:58 pm
Greg,
Would you respond to the following post concerning your stairway. Thanks.
http://www.sqlservercentral.com/Forums/Topic1489336-90-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
July 28, 2014 at 9:43 am
I would like to get started with these...
DML:
http://www.sqlservercentral.com/stairway/75773/
Advanced T-SQL:
http://www.sqlservercentral.com/stairway/104497/
The only thing I could not determine is which version of SQL Server Express I should install and what database these are written for (ie: Adventure Works)?
Thanks!
May 21, 2015 at 1:38 pm
I don't know that much about MERGE. It sort of scares me. We've managed to create all of our stored procedures without it.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply