I'm in the process of rewriting a stored procedure at my new job. Currently, it's running another stored proc to generate data, using a function to customize that data, and then inserting it into a table for each customer, one at a time. The amount of data for each customer is about 6k rows (no blobs). It's not a lot of data but it can be slow (5 to 10 minutes) once you include the fact that the stored proc is also doing emails, ftping, etc. It's a mess.So, unfortunately, I'm not going to be able to do anything about calling the secondary stored procedure and using the function to get data. Unfortunately, it has to be done that way. However, my thought was that because the data changes sporadically it might be better to keep a third table with indexing online, and only making changes when there's a delete, update, new record. So, instead of generating a new table with 6k rows 100 times, several times a day, I use either a merge or custom inset/update/delete to make changes only to the ones that need them. I then pull the data from that third table.I don't use merge statements a lot and I'm curious in the background workings of the statement. My guess is that it's running something similar to a select to pull data that needs changes and then determining if there are other inserts/deletes that need to be made. Is this going to be quite a bit faster than the current process? Is it also going to be faster than if I do my own customer script for checking existing records?Thanks
↧