Re: ORM doctrine

On Sunday, 12 December 2010, Lester Caine <lester@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. Regards Peter -- <hype> WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 </hype>