Thanks all for your input, very helpful. And yes, there will be 500 separate connections to the db per seconds, each updating 1 record. I've read about setting PRAGMA synchronous=OFF to cause SQLite to not wait on data to reach the disk surface, which will make write operations appear to be much faster. "But if you lose power in the middle of a transaction, your database file might go corrupt"==> I can live with this risk if it makes an huge improvement with the possible contention issue I'm facing. Any input with this setting you can provide will be greatly appreciated as always. Robel
-----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Simon Slavin Sent: Thursday, June 11, 2009 4:49 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] Advice on which to use (SQLite or SQL Server) for the following app. 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
