my two cents... I used to work at a newspaper we used a very elaborate caching system, it used to function at the at the page subcomponent level (i.e. header, footer, left nav, articles were all stored separately) AND page level. The page subcomponents were cached together as pages. This was a good system because it allowed for the subcomponents to be updated without effecting the pages (by deleting the subcomponent cache and leaving the page cache), then subcomponents were regenerated with new contents, and finally the page caches were deleted and the pages were then regenerated from the cached subcomponents (which was the same speed as doing SSI's basically). Anyway, a fast system, a bit complex, a bit ridged (if you want dynamic stuff in your pages) but solid for a newspaper.
Now on to DB caching... ADODB has support for Database caching, it basically dumps the database to a file and reloads it transparently when you next do the same select on the DB. This would work if you coupled it with a publish event... i.e. DB changes -> have a script SSH to the web servers and delete the cache / or pregenerate the cache on the db server and upload it to the webserver as a temp file and then do a mv to the real cache file... many ways to skin that cat. -Garth Northern.CA ===-- http://www.northern.ca Canada's Search Engine -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
