When it comes to denormalizing data in a transactional database for performance, there are (at least) three different approaches:
Push updates through stored pr
It depends on your business requirements and how your database is used. For instance, suppose there are many applications and many imports that affect the table (we have hundreds of things that can affect our tables) . Suppose also there is occasionally the need to write queries that are run from SSMS (yes even on prod) to do things like update all prices by 10%. If you do these types of things then a stored proc is impractical, you will never have every possible way to affect the database covered.
If this data change is necessary to data integrity or many applications or processes (imports, SQL Server Jobs, etc.) can affect data, then it belongs in the trigger.
If the data change is needed only sometimes or you have total control of how data is changed from only one application, then a stored proc is fine.