title: Where's the tradeoff between normalization (SQL View) and performance/fiability (SQL Table)
body: <p>I've got quite a long business process which eventually results into financial operations.</p>
  
  <p>What matters in the end is quite exclusively these final operations, although I've got to keep a log of everything which led to it.</p>
  
  <p>Since all the information contained into the final operations is available in other tables (used during the business process), it makes sense to use a view, but the view logic would be quite complicated (there are dozens of tables implicated), and I'm concerned that :</p>
  
  <ol>
  <li><p>even with appropriate indexes, a table will probably be way faster (my table will eventually contain millions if items, and should be fully searchable on almost all its columns)</p></li>
  <li><p>the view logic would be complicated, so I'm afraid it may complicate things in a few years if I want to evolve my business logic.</p></li>
  </ol>
  
  <p>Because of those two reasons, I'm a bit tempted to write the data in a table at the end of my business process instead of relying on a view, but duplicating the data doesn't smells right (and it also looks a bit like premature optimization, but since it's such a central point in my design, I'd like to address the issue ASAP)</p>
  
  <p>Have you ever faced such a choice? What did you decide?</p>
  
  <p><strong>Edit :</strong> creating a table would clearly lead to duplication in my situation, ie. the data written in the table exists somewhere else in the database and could be retrieved using only joins without any calculations.</p>