title: handling history/change tracking in the DB and consequences on the BL
body: <p>in the current application im working on the client requested that we will save history of every action that happended in the system and provide the ability to backtrack to the previous state of the information.</p>
  
  <p>for example: lets say that my app need to handle a storage-room and each user can add/update/delete/read (all CRUD) the inventory</p>
  
  <p>if the user added product P1 with action A1 and updated its info so it becomes P2 with action A2 and later on P3, P4 and so on. in the application the user will have a screen that will show all the evolution of the product and ascreen that shows all the actions that were made by users.
  the user could select a certain action and "undo" it.</p>
  
  <p>at first glance i thought that i will store some kind of a Actions table with all the info i need about the action and when i need to undo and action i just revert the changes in code.</p>
  
  <p>my problem is: if the product is not stored in one table but divided to few tables (because of optimization/understandability etc.) i need to figure out where exactly were the changes.</p>
  
  <p>should i keep an indication in the Actions table of what tables were influenced and reflect it to the BL????</p>
  
  <p>seems to me that there must be a better solution</p>