title: Best practice for revision control of data in SQL databases
body: <p>My entire database occasionally has entries which are wrong, but instead of altering the data directly I'd like the ability to keep a revision of changes. </p>
  
  <p>These changes occur very rarely.</p>
  
  <p>Ideally something like this: -</p>
  
  <pre><code> (original table fields) | revision_version | origin | user | timestamp
  </code></pre>
  
  <p>So say I had a table called <strong>posts</strong> with the following schema: -</p>
  
  <pre><code>title | description | timestamp | author
  </code></pre>
  
  <p>An additional table called <strong>posts_revisions</strong> would be created thusly: -</p>
  
  <pre><code>title | description | timestamp | author | revision_version | origin | user | timestamp
  </code></pre>
  
  <ul>
  <li><strong>origin</strong> being the source of the change, be it a bot, user generated or what have you.</li>
  </ul>
  
  <p>As you can imagine this is a rather large change to the existing database, my current concern is the performance hit of checking the _revisions tables for every query. Is this best practice for this sort of thing?</p>