JoshDBGuy (8/4/2015)
Grant Fritchey (8/4/2015)
You're better off doing custom scripts. MERGE can, and does, function. But, it's not very tuneable. You get a single execution plan for the INSERT/UPDATE/DELETE regardless of which is used to compile the plan. It makes it very inflexible. If you need the ability to tune the query, you'll have to customize, so why not start there. It's not much more work, about the same really.Makes sense. I was going to test it out anyway but was curious if anyone had experience. Is it best practice in general to not use Merge?
I don't know that I'd go that far. I'm less than pleased with the flexibility and the ability to tune MERGE. But, it can be functional. On the other hand, I haven't hit some of the issues that others have and, especially when I see Jason and others saying not to, I tend to shy away. I'm not prepared to lump it in with multi-statement table-valued user-defined functions as an unclean process yet.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning