title: database transactions when 'consistent state' / 'atomicity is not needed
body: <p>I'm tryin to understand when to use database transactions if I don't have the need for consistent state or "strict" atomicity.</p>
  
  <p>I don't have some banking style requirement that needs a reduction in one column to offset an addition somewhere else.</p>
  
  <p>I do have some form of atomicity, but only for 'ease of use' and I'm wondering if that's enough to use a db transaction.</p>
  
  <p>Specifically, I require my user to create an entry in table A, B and C. Table C depends on B and B depends on A. On the browser I actually display all that data in one form and when the user submits, it is sent to the backend where an entry in table A is attempted, followed by B (with the reference Id just created from A), followed by C (with the reference id created from B).</p>
  
  <p>If A fails, the User is reshown the form with the error message regarding A.
  If A succeeds, but B fails, then the user is redirected to a page to add B &amp; C. 
  If A &amp; B succeed and C fails the user is redirected to a page to add C. </p>
  
  <p>As you can see this can be quite a lot of error handling and a transaction that just says "All succeeded" or "something failed, nothing created", would be the easiest since I could just keep the user on the same page or redirect if successful. Also keep in mind the likelihood of failure on B &amp; C is quite low since I do validation on client side...</p>
  
  <p>My question is when should I be using the transaction approach vs the error handling approach when my need for atomicity is not so "strict". What are some considerations I need to make before choosing a transaction approach or a series of inserts approach. </p>