> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On > Behalf Of Olivier Mascia
> If I'm permitted: you're wrong. Ha, yes, well if our initial threading model is anything to go by, I think you're on safe ground with that assertion. > Unless you have a very complex schema (I would say at the very least more > than on hundred tables and other create statement), opening a SQLite > connection is lightweight, We currently have 500 tables and 1500 triggers in the schema. Perhaps that is why we didn't have much luck having one connection per thread or opening a connection per access. Perhaps our schema needs a rework, would one table with a million rows be better than 500 tables with 2000 rows each? We were considering adding a view per table too, that would make it 3000 elements in the schema, if 100 is considered a lot are we attempting to use sqlite in a manner that it is not suited for? We may need to consider another alternative if that's the case, although that would be a shame. > is lightweight, especially compared to whatever experience you > might have had with quite any other SQL system. Sadly we are not comparing sqlite with another SQL DB. We are attempting to replace an in-house memory resident non-sql database with sqlite. So our comparison is between a) reading from memory and b) opening a connection and reading from sqlite. > you intend to loose on both of them (pooling connections > and sharing them across threads at the cost of mutual exclusion contention > to get it working). Believe me that we would like nothing more than to do what you suggest, we will be looking into any way possible to get this implemented in the optimal manner. Thanks a lot for giving your advice. Merci Alex _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
