|
|
Posted by Jerry Stuckle on 01/05/08 14:05
flowover wrote:
> On Jan 4, 6:46 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Rowan wrote:
>>
>>> What is the best approach to caching database results. example say i'm
>>> doign an update on several entries which i've loaded into an array. I
>>> want to allow the user to click through and up date each array entry
>>> then dump everythign to the db once they are done...
>> Don't bother. It's normally cheaper to just keep track of the ID's and
>> fetch the results again.
>>
>> You should be fetching them again before updating anyway, and verifying
>> the rows haven't changed (i.e. two people updating at the same time).
>>
> If you're writing the site to scale then yes, plan for multi users
> being in there changing. If the site is just an administration
> backend that you know isn't going to have more than one person making
> changes at a time, stuff that array in a session. This requires
> either a big ugly key in your URL or a cookie though, but imo is the
> best way to cache data between requests.
>
You should ALWAYS write the site to scale. It's not any harder. And
even if it is just an "administrative back end", are you SURE there will
never be two administrators changing at the same time?
Such "assumptions" are traps waiting to spring.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|