Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>First off, this sounds like a premature optimization. As Steven pointed out, most sane databases are going to put you into a transaction anyway, and all they're really doing is calling commit after each statement. So from that perspective, autocommit might be less performant since each statement has to start a new transaction. Or maybe not. Only benchmarking will tell and I bet it doesn't make one lick of difference to your application.</p> <p>One reason why you want to always use a transaction is consistency of protection. If you start fiddling with manually declaring a transaction only when you "need" then then you're going to forget at a critical time. Or that supposedly read-only set of operations suddenly isn't, either because a later programmer didn't realize it was supposed to be or because your code calls a function which has a hidden write. For example, I configure my command line database clients not to autocommit. This means I can fat finger a delete query and still rollback.</p> <p>There's the isolation level, as pointed out. This allows you to do several reads without worrying if some other process has written to your data in between them making your reads effectively atomic. This will save you from many an hour debugging a race condition.</p> <p>And, finally, you can often set a transaction to be read-only. This checks your assumption and will error out if something tries to write.</p> <p><a href="http://www.oracle.com/technetwork/issue-archive/2005/05-nov/o65asktom-082389.html" rel="noreferrer">Here's a nice article summing it all up.</a> The details are Oracle specific, but the concepts are generic.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload