title: Best Practice for Versioned Entities?
body: <p>Good afternoon,</p>
  
  <p>I am currently in the very early phase of a new project written in .Net and using Entity Framework for data persistence/storage. One of the features required is the ability to 'version' certain model types. E.g. one model is one 'Requirement' which will have n 'Requirement Versions', basically having a way of going back in the history/lifecycle of that particular 'Requirement' instance. The only thing that has to be static across all revisions is it's 'ID', everything else is absolutely changeable throughout the requirement's lifetime. </p>
  
  <p>Now the Q is, should I 'simply' create a 1:n relationship between a Requirement >> RequirementVersion? Other features need are the possibility to completely revive old states to be the current/latest one, there must be the ability to have minor and major version (changes) and such, and last but not least the ability to create a 'Baseline' across a collection of Requirements with the latest version to go back to that particular Baseline at a later point of time and displaying all of the included RequirementVersions?</p>
  
  <p>This has to scale up to a couple million Requirement Records, each of them having a couple thousand revisions.. that's particularly why I am asking.. the scaling aspect of a simple 1:n relationship etc.</p>
  
  <p>Has anyone done something similiar and maybe some suggestions/best practices etc regarding versioning/baselining etc?</p>
  
  <p>Cheers &amp; thanks,
  -Jörg</p>