title: Design pattern good for many entities history?
body: <p>I have some entity classes in my application. I want to save all changes to this entities and some happened events in a history table. Problem is that entity classes are different, build with different primitives and different relation between them.</p>
  
  <p>For example in a shopping application there can be: User, Item, Transaction, Watch. I want to be able to show some activity log to user like this:</p>
  
  <ul>
  <li>16:00 You've bought "Lord of the Rings" in a transaction 2468,</li>
  <li>15:30 You've added "Hobbit" to your watchlist,</li>
  <li>15:00 Watched item's "Silmarillion" has dropped price from 15 to 12,50 euro,</li>
  <li>14:30 You've changed your name from "Tomasz" to "Tom".</li>
  </ul>
  
  <p>There are many things involved in this log: </p>
  
  <ul>
  <li>new Transaction entity 2468 with Item "LotR", </li>
  <li>new Watch entity linked with Item "Hobbit" and my account,</li>
  <li>updated Item price (but both old and new prices are stored),</li>
  <li>updated User name (both old and new stored).</li>
  </ul>
  
  <p>My main question is how to keep track of these data?</p>
  
  <ol>
  <li>Should I have as many tables as many entity tables to keep their changes? UserVersions, ItemVersions etc?</li>
  <li>Should I query all Version tables, join and sort results to generate this log?</li>
  <li>Or maybe there should be one table Versions with columns "Entity", "OldValue", "NewValue" - what about constraints and foreign keys? Isn't it too dirty solution?</li>
  <li>Is there design pattern for this?</li>
  <li>Finally if you know - how does Facebook does this? :)</li>
  </ol>