On 11 Jun 2009, at 8:23am, Roger Binns wrote: > It depends very strongly on how the app is structured and in > particular > if there are a few persistent connections to the SQLite database, or > if > each request involves a separate connection to the database. If you > have lots of connections then there will be contention.
500 connections a second, each from a different computer. If the OP handles each one with a separate run of his/her application, that's 500 connections to the database a second, each updating one record in one table. > If the work done during contention is quick and simple then you are > fine. If it is long running then you will benefit from a server based > approach. But when you have commits then disk access is serialized > and > you will have performance limitations no matter what the database > server or SQLite. (That is the point Florian is making.) As far as I can tell, with correct programming each query would be one connection for all the data the query would want. So the OP's objective is /probably/ achievable with SQLite but I'd want to prototype it to be sure. Sorry, Robel, but we can only guess. Try it. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
