|
|
Posted by Jerry Stuckle on 01/06/08 19:13
Gary L. Burnore wrote:
> On Sat, 05 Jan 2008 09:05:49 -0500, Jerry Stuckle
> <jstuckle@attglobal.net> wrote:
>
>> 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.
>
> You can tell him what to do but not how? Some trainer YOU are.
>
> How's that "ignoring me" thing going, Jerry?
Nope, I don't need to ignore you, Gary. I OWN YOU. And you keep
proving it. ROFLMAO, ignorant twit.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|