On 8 Jun 2013, at 5:27pm, RSmith <[email protected]> wrote: > Thank you very much for taking the time - this did answer my question.
You're welcome. > If I may one more question related to this: Let's say I am using > transactions as validation stops on a long list of inputs - So > that the main program does some checking along the way, I have two choices, I > can start with a BEGIN and do COMMIT at the very end, > and possibly ROLLBACK everything once I get an error and start over. > Alternatively (and this is obviously what I want to do), I can > do BEGIN, then check say 1000 records, then COMMIT, then BEGIN, check 1000, > COMMIT, etc. This way if I get an error, I need only > rollback a little bit. > > The question is, how high is the overhead on BEGIN-COMMITs? I don't know the really detailed answer to this. If you care down to the millisecond then the answer depends on which journaling mode you're using, and on technical details about your operating system and file system. The problem is that the actual time varies tremendously depending on how cheap and nasty your hard disk is, whether your databus is choked and other stuff we can't guess. Frequent advice on this list is to assume that you will want to batch your transactions somehow, and put your 1000 into a variable you can change. Then try your app with several different values for the variable. If I understand your description then setting this variable to 1000000 would be equivalent to your other scenario: just doing everything in one huge batch. You don't make complicated changes each time, you just change the number in one line of code. The opposite advice is this: version 1 of your code should ignore timing and just do whatever reflects the way your data relates to real life. Just think about what your data really 'means' and use transactions and SAVEPOINTs that reflect that. Then run your app. A second or two either way isn't anything to care about. Only if your app is /unacceptably/ slow do you then have to start worrying about writing contra-intuitive code. And with those two pieces of advice, I hope I have covered all bases in an unbiassed manner. I hope you can forgive me for the fact that they contradict one-another. Simon. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
