SQL Server history tracking of a table with multiple same referencing column -

in database design, i'm tracking history triggers. first of all, have base table goods following columns:

tablename: goods column1pk: goodid column2: articlecode column3: amount 

i want track operations made on goods, insert, delete or replace (not changed values of columns) . there can insert, update, delete or replacement of good. example, goodid 1 has reached it's lifetime , getting replaced goodid 2. able capture information, can't see other option having second column in history table referencing same goodid table goods

my history table be:

tablename: goodshistory column1pk: goodhistoryid column2: changedby column3: datechanged column4: actiontype (like inserted, updated, replaced or deleted) column5fk: goodid (capture insert/update/'fake'-delete operation) column6fk: replacedbygoodid (capture `goodid` replaced `goodid`) 

see record-set example of history data:

column1pk:  |  1          |  2           |  3           |  4 column2:    |  user1      |  user1       |  user1       |  user2 column3:    |  10/12/2012 |  12/16/2014  |  12/16/2014  |  12/16/2014 column4:    |  inserted   |  inserted    |  replaced    |  inserted column5fk:  |  1          |  2           |  1           |  3 column6fk:  |  null       |  null        |  2           |  null 

short explanation: goodid 1 exists since 2 years, , today user1 created new goodid , replaced old 1 new one. also, user2 created new goodid 3.

i'm working in sql server 2008 r2, , sql don't multiple cascading paths. cascading path exists because column5fk , column6fk both refer goodid. 1 of 2 relationships allow cascade while other forced take no action upon update/delete operations, resulting in non delete-able goods if both fk-relationships's set. (so in case, cannot update/delete goodid 1 , 2.)

a workaround trigger. since have few tables have same setup, require me create/edit triggers each table tracks history same way, , i'm afraid of additional overhead managing problems upon database schema changes.

so question if there other, maybe smarter design/solutions kind of information gathering, or if should stick 1 due limitations of sql server.

imho need more 1 table history, first keep records goods, , main table have references. e.g.

goodsactions {id, goodid, action}  goodshistory {userid, goodsactionsid, setid}  

where setid aggregate single history entry logical operations.