Samuel R. Neff wrote: > > > You could maintain a queue in memory of all the data to be written, have > each page view queue up the new data and have a single db writer thread > that > dequeues items and writes to the db. That way you get the benefit of > writing directly to the db, but do not have the extra overhead on each > page > view of writing to the db. There is a risk of data loss for whatever is > queued up and not yet written to the db but as long as you're running the > writer thread often enough it's not a great concern (especially since the > data is not critical in that if you lose a few records it's no big loss). > > By batching the writes you also can take advantage of transactions to > speed > up writes. > > HTH, > > Sam >
Thank you! I like the idea of batching the writes and dispensing with the intermediate flat file. However, it is not clear to me where I would run the dequeuer from. The only thing I can think of is running the dequeuer as a PHP script which I arrange to call every few minutes. I can certainly do this from one of my development machines and there is probably a way to run the script directly on my server but I don't know of that. What did you have in mind? -- View this message in context: http://www.nabble.com/Would-SQLite-be-a-good-choice-tf4821074.html#a13794975 Sent from the SQLite mailing list archive at Nabble.com. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
