title: Database design for create/revise/delete request form
body: <p>I am working on a web application that replaces paper-based forms to request creation/revision/deletion of courses, and I need help on the best database design practices for storing the requested items. </p>
  
  <p><strong>Note</strong></p>
  
  <ul>
  <li><p>The database is just for requested data. Once the request is approved, the data must be manually entered into a different system. ( we have no control over this)</p></li>
  <li><p>Request could be revised multiple times before it gets approved, and we need the revision history of each request</p></li>
  <li><p>We need to track statuses for each request</p></li>
  <li><p>There are 30+ questions to create a course</p></li>
  <li><p>There are 3-30+ questions to revise a course (depends on how many items need to be revised)</p></li>
  <li><p>There are 5 questions to delete a course</p></li>
  </ul>
  
  <p><strong>My Approach 1</strong></p>
  
  <p>In this approach, I would store all data for create/revise/delete in the <code>RequestDetail</code> table. Since each <code>RequestDetail</code> can have multiple items such as <code>CourseMode</code> (e.g. online, face-to-face), there are some tables associated with each <code>RequestDetail</code>.
  <img src="https://i.stack.imgur.com/FlHyb.png" alt="enter image description here"></p>
  
  <p>The table below is an example: 
  When a user requested to create a course (<code>RequestID:1</code>), there are two revisions (title and fee changed) until it gets approved. But all columns for Revision and Deletion are <code>NULL</code>.</p>
  
  <p>When a user requested to revise a CourseFee (<code>RequestID:2</code>), the user enters the new fee and the reason for revision, and the remaining columns for Creation and Deletion are <code>NULL</code>.</p>
  
  <p>When a user requested to delete the course (<code>RequestID:3</code>), the user enters the reason for deletion, and again the remaining columns are <code>NULL</code>.</p>
  
  <p>Since the purpose of this data is more like a data warehouse, could this be simple and easy to handle? But the table needs to allow Nulls for almost all fields (for creation, most of fields are required).</p>
  
  <p><img src="https://i.stack.imgur.com/4K2ZR.png" alt="enter image description here"></p>
  
  <p><strong>My Approach 2</strong></p>
  
  <p>In this approach, revisions of requests are handled the same way as the first approach, but create separate tables for Revisions and Deletions. But this approach seems redundant and not clean. </p>
  
  <p><img src="https://i.stack.imgur.com/BKPxi.png" alt="enter image description here"></p>
  
  <p>Personally I prefer the first approach but what the best database design practices would be in this case? Is there anything I overlooked or I need to be careful of?</p>