On 27 Jan 2010, at 1:28pm, Tim Romano wrote: > The question in my mind is whether the following is any more > performance-efficient than the approach above (note 2a-2e and 5a-5b): > 2. Webservice: > 1) receives the request > 2) instantiates a database connection > 2a) creates an in-memory database > 2b) attaches in-memory database
Hmm. A couple of things worth considering: first that JavaScript under HTML5 has its own access to SQL commands. If this system is for use only inside an organisation, and you can say everyone must use a modern browser, then you can use the HTML5 tools which automatically ensure keep the databases local (in fact, on the client's hard disk, not the server !). By the way, all the browsers I've seen that support this actually use sqlite3 internally. However, you might be planning to do this on the server using PHP. And PHP has more than one SQLite library and you should be sure you're using one that uses sqlite3, not the original sqlite library. So part of your design decision is whether some of the presentation work can be done in JavaScript on the client. > 2c) issues query to disk-database to fetch random hex value to > ensure temp table is named uniquely You don't need this. If you're using a TEMP table, or keeping the table in :memory:, then you can call it whatever you want: only the single connection you're using right now can see it, and it will vanish as soon as Apache (or whatever) has finished serving that particular web page. [later: I see Jay explained this bit better, so read his response.] Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
