Michael Hooker wrote: > This is an issue which interests me too. The answer Scott gives makes > absolute sense to me, but all the PHP/MySQL books I've seen (and MySQL can't > be that different from Sqlite3 in this respect) seem to go the way of a new > query to the database every time a different set of data is needed, rather > than keeping all the data in an array, even with small inconsequential > tables. I suppose if there is a possibility that the db tables may be > updated while the user is online this approach is valid. Or maybe there is > a downside to PHP arrays, I can see that a huge array might have memory > implications, especially on a busy shared server.
My experience has been that each sqlite DB hit on my server takes about .01 seconds to run. So if you're hitting that DB 20 times to get the 20 most popular images that really adds up. I've spent countless hours optimizing my site to do things like: SELECT * FROM Entry WHERE ID IN (1,2,3,4); instead of SELECT * FROM Entry WHERE ID = 1; SELECT * FROM Entry WHERE ID = 2; SELECT * FROM Entry WHERE ID = 3; SELECT * FROM Entry WHERE ID = 4; If you can (sometimes its hard programatically) reducing the number of database hits will always speed up your application. Unless of course the data you're loading in RAM is huge. When you're storing megs of data in ram just to speed up your queries you probably should look at other routes for optimization. -- Scott Baker - Canby Telcom RHCE - System Administrator - 503.266.8253 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
