On Sunday, 12 December 2010, Lester Caine <les...@lsces.co.uk> wrote:
> Peter Lind wrote:
> I may have misunderstood the topic, but a cache to me is more than
> just storing views. It's also the db cache, memcache, apc, etc. You
> have to think about how you use these - some of them can't just be
> slapped on to your app after development.
>>>  Data caching SHOULD always be the
>>>  domain of the database, so duplicating that in PHP is pintless.
> So you're saying one should never use memcache for storing data from the db?
> That is probably one of the areas where care should be taken in WHAT you are 
> caching. CURRENTLY too much caching goes on

I have not seen this problem but I have often seen sites not caching
things they should, so I'd say you're wrong. I don't think its
relevant one way or the other though.

> memcache may well be a candidate to use for a cached list of choices for a 
> form, but on a distributed database ( such as Firebird ) then how do you KNOW 
> if the list has been updated?

This is relevant to very few developers. Much more relevant is the
overhead used in contacting the single mysql/postgresql/etc database
that your provider put on another machine.

> Only the database actually knows that, and a good database will provide ALL 
> of the data caching that you need ... or at least it should if the DATABASE 
> is designed correctly.

See above.
> The reason for 'caching' needs to be understood before it is applied in order 
> to avoid the black holes that random caching is causing nowadays already. How 
> often do you hear "wipe the xxx browser cache"? And I know if I am changing 
> theme elements in bitweaver or phpgedview then I HAVE to wipe the cache to 
> ensure that smarty rebuilds the relevant pages.

Which underlines my point: caching is not icing on the cake but should
be thought of sooner in the process, contrary to Tommys point.


WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to