Philosophy on stored procedures that perform updates: is a 'granular' update approach sufficient?
Stored procs are the programming API of the database, the methods you invoke to mutate the system state. As such, I prefer to have SPs names reflect the business outcome desired rather than the implementation - change_of_address rather than update_customer. Each SP has the parameters to perform that business change and no others. Each does one thing and does it well.
If the business supports two processes that both update a common column then so be it. That column is an input to each of those SPs. Say there's a web based &quot;change profile&quot; and a mobile-only &quot;register new phone&quot;. They both write to customer.phone_number. I would have separate SPs for each business purpose.
There is no measurable overhead to having many small, tightly focused stored procedures. Changes to data types are automatic on the next recompile. Changes to column names are simple search-and-replace. SSMS's built-in dependency analysis can help, too. If you use local variables that mirror columns use the column's name e.g. customer_name is read into @old_customer_name.