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...
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).
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
On Jan 4, 6:46 pm, Jerry Stuckle
> 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).
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================
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.
On Jan 5, 5:13 am, flowover
> On Jan 4, 6:46 pm, Jerry Stuckle
>
> > 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).
>
> > --
> > ==================
> > Remove the "x" from my email address
> > Jerry Stuckle
> > JDS Computer Training Corp.
> > jstuck...@attglobal.net
> > ==================
>
> 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.
Note that the database result is a resource though, and you can not
serialize a resource. You have to actually put every result into an
array to store it. Jerry has a huge point when he says that it's
usually cheaper just to fetch it again.
flowover wrote:
> On Jan 4, 6:46 pm, Jerry Stuckle
>> 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
==================
Jerry Stuckle;111941 Wrote:
>
> 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.
>
Can you suggest some links/tutorial on scaling a site?
FFMG
--
'webmaster forum' (http://www.httppoint.com) | 'Free Blogs'
(http://www.journalhome.com/) | 'webmaster Directory'
(http://www.webhostshunter.com/)
'Recreation Vehicle insurance'
(http://www.insurance-owl.com/other/car_rec.php) | 'Free URL
redirection service' (http://urlkick.com/)
------------------------------------------------------------ ------------
FFMG's Profile: http://www.httppoint.com/member.php?userid=580
View this thread: http://www.httppoint.com/showthread.php?t=23913
Message Posted via the webmaster forum http://www.httppoint.com, (Ad revenue sharing).
FFMG wrote:
> Jerry Stuckle;111941 Wrote:
>> 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.
>>
>
> Can you suggest some links/tutorial on scaling a site?
>
> FFMG
>
>
Wish I could, but I haven't seen any sites with such information all in
one place. Bits and pieces here and there, but that's all.
Maybe someone else has a better answer.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
On Jan 6, 1:45 am, FFMG
> Jerry Stuckle;111941 Wrote:
>
>
>
> > 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.
>
> Can you suggest some links/tutorial on scaling a site?
>
Note: skip to the bottom for some useful links.
Scalability isn't addressable in a single point, you first have to
determine
the what and why you need to scale. It's really easy to say "You
should always
write your code to scale" and of course, those people should be shot.
It isn't
useful and doesn't tell you anything and if there is one thing I've
learned, when
an application goes from development to the users, they will
invariabley find a
way to make it die().
So, where does that leave us? There was an old addage about
scalability, which was
if you are building an app you expect to support 100 users, design it
to support
1000 users, if you are building it to support 1000 users, design it to
support
10,000 users, etc.. etc..
You can design an app perfectly to support 1 million users but if you
only have
a dialup connection, it won't do you much good. Scalability covers
everything
not only from the code perspective but down to your network
perspective (lb's,
reverse caching, memcache, redundant bandwidth, redundant servers,
etc)
Start with the IBM series of articles (note, I do not work for IBM):
http://www.ibm.com/developerworks/linux/library/l-tune-lamp- 1/#resources
http://www.ibm.com/developerworks/linux/library/l-tune-lamp- 2.html?ca=dgr-lnxw01LAMPTuningP2
http://www.ibm.com/developerworks/opensource/library/os-php- fastapps2/
Those should cover your basics of the single server and php, google
the rest out
for load balancing, caching, etc.
Post removed (X-No-Archive: yes)
faulkes wrote:
> On Jan 6, 1:45 am, FFMG
>> Jerry Stuckle;111941 Wrote:
>>
>>
>>
>>> 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.
>> Can you suggest some links/tutorial on scaling a site?
>>
>
> Note: skip to the bottom for some useful links.
>
> Scalability isn't addressable in a single point, you first have to
> determine
> the what and why you need to scale. It's really easy to say "You
> should always
> write your code to scale" and of course, those people should be shot.
Nope, you should write your code to scale. But scalability varies.
> It isn't
> useful and doesn't tell you anything and if there is one thing I've
> learned, when
> an application goes from development to the users, they will
> invariabley find a
> way to make it die().
>
That's because there is no one part of scalability. In any one
application there may be one or dozens of different things you can do
for scalability. And he asked for a site which has info. As I said - I
don't know of a single site.
And programs won't fail if they've been properly designed and tested.
I'm not saying they're going to be perfect. There's no such thing.
However, a proper development process will keep them from dying.
> So, where does that leave us? There was an old addage about
> scalability, which was
> if you are building an app you expect to support 100 users, design it
> to support
> 1000 users, if you are building it to support 1000 users, design it to
> support
> 10,000 users, etc.. etc..
>
Exactly.
> You can design an app perfectly to support 1 million users but if you
> only have
> a dialup connection, it won't do you much good. Scalability covers
> everything
> not only from the code perspective but down to your network
> perspective (lb's,
> reverse caching, memcache, redundant bandwidth, redundant servers,
> etc)
>
But the app is the hardest to change. It's much easier to change from a
dialup connection to a T-3, for instance.
> Start with the IBM series of articles (note, I do not work for IBM):
>
> http://www.ibm.com/developerworks/linux/library/l-tune-lamp- 1/#resources
> http://www.ibm.com/developerworks/linux/library/l-tune-lamp- 2.html?ca=dgr-lnxw01LAMPTuningP2
> http://www.ibm.com/developerworks/opensource/library/os-php- fastapps2/
>
> Those should cover your basics of the single server and php, google
> the rest out
> for load balancing, caching, etc.
>
Those are good for what they say. But they're by no means complete.
There is a lot more to scaling, even on a single server.
So your answer is telling him to google? Gee, can't you do better than
that?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Post removed (X-No-Archive: yes)
Post removed (X-No-Archive: yes)
Gary L. Burnore wrote:
> On Sat, 05 Jan 2008 09:05:49 -0500, Jerry Stuckle
>
>
>> flowover wrote:
>>> On Jan 4, 6:46 pm, Jerry Stuckle
>>>> 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
==================
On Jan 6, 1:39 pm, Jerry Stuckle
> And programs won't fail if they've been properly designed and tested.
> I'm not saying they're going to be perfect. There's no such thing.
> However, a proper development process will keep them from dying.
Apparently you've never given something to a user to play with.
>
> > You can design an app perfectly to support 1 million users but if you
> > only have
> > a dialup connection, it won't do you much good. Scalability covers
> > everything
> > not only from the code perspective but down to your network
> > perspective (lb's,
> > reverse caching, memcache, redundant bandwidth, redundant servers,
> > etc)
>
> But the app is the hardest to change. It's much easier to change from a
> dialup connection to a T-3, for instance.
Nobody is saying don't code well or don't follow best practices or
have
procedures in place. As stated, scalability is not single faceted and
the dirth of apps dying on Black Friday or any given successful launch
are
proof positive of it isn't.
> >http://www.ibm.com/developerworks/linux/library/l-tune-lamp -1/#resources
> >http://www.ibm.com/developerworks/linux/library/l-tune-lamp -2.html?ca...
> >http://www.ibm.com/developerworks/opensource/library/os-php -fastapps2/
>
>
> Those are good for what they say. But they're by no means complete.
> There is a lot more to scaling, even on a single server.
>
As stated, they are a start, which is far better than you offered. So
apart
from snide remarks and a complete failure to actually provide
something useful,
do you actually have anything to add?
> So your answer is telling him to google? Gee, can't you do better than
> that?
Yes, I refer you to the almighty fact that you didn't give him a
nickels
worth of url he could so much as peruse.
Added that given how trivial it is once you get started to google for
the rest,
he shouldn't have too much of a problem and even be able to come back
here and
ask questions if he needs.
Or he could hire me.
Post removed (X-No-Archive: yes)
Post removed (X-No-Archive: yes)
faulkes wrote:
> On Jan 6, 1:39 pm, Jerry Stuckle
>> And programs won't fail if they've been properly designed and tested.
>> I'm not saying they're going to be perfect. There's no such thing.
>> However, a proper development process will keep them from dying.
>
> Apparently you've never given something to a user to play with.
>
I've been programming for around 40 years now. I've worked on a lot of
projects in that time. Those which were not managed well had the
problems you describe. But those which were well-managed did not.
As I said - I never claimed even the well-managed projects were
error-free. But they didn't fail.
>>> You can design an app perfectly to support 1 million users but if you
>>> only have
>>> a dialup connection, it won't do you much good. Scalability covers
>>> everything
>>> not only from the code perspective but down to your network
>>> perspective (lb's,
>>> reverse caching, memcache, redundant bandwidth, redundant servers,
>>> etc)
>> But the app is the hardest to change. It's much easier to change from a
>> dialup connection to a T-3, for instance.
>
> Nobody is saying don't code well or don't follow best practices or
> have
> procedures in place. As stated, scalability is not single faceted and
> the dirth of apps dying on Black Friday or any given successful launch
> are
> proof positive of it isn't.
>
>>> http://www.ibm.com/developerworks/linux/library/l-tune-lamp- 1/#resources
>>> http://www.ibm.com/developerworks/linux/library/l-tune-lamp- 2.html?ca...
>>> http://www.ibm.com/developerworks/opensource/library/os-php- fastapps2/
>>
>> Those are good for what they say. But they're by no means complete.
>> There is a lot more to scaling, even on a single server.
>>
>
> As stated, they are a start, which is far better than you offered. So
> apart
> from snide remarks and a complete failure to actually provide
> something useful,
> do you actually have anything to add?
>
Other than the fact you've offered very little other than 3 links he
could have easily found in google? Big deal.
>> So your answer is telling him to google? Gee, can't you do better than
>> that?
>
> Yes, I refer you to the almighty fact that you didn't give him a
> nickels
> worth of url he could so much as peruse.
>
That's because I don't have on particular site. The links you gave were
OK - but not at all complete.
> Added that given how trivial it is once you get started to google for
> the rest,
> he shouldn't have too much of a problem and even be able to come back
> here and
> ask questions if he needs.
>
> Or he could hire me.
>
Yep, and get an application which will fail as soon as he gives it to a
user.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Gary L. Burnore wrote:
> On Sun, 6 Jan 2008 11:17:45 -0800 (PST), faulkes
>
>
>> On Jan 6, 1:39 pm, Jerry Stuckle
>>> And programs won't fail if they've been properly designed and tested.
>>> I'm not saying they're going to be perfect. There's no such thing.
>>> However, a proper development process will keep them from dying.
>> Apparently you've never given something to a user to play with.
>>
>>>> You can design an app perfectly to support 1 million users but if you
>>>> only have
>>>> a dialup connection, it won't do you much good. Scalability covers
>>>> everything
>>>> not only from the code perspective but down to your network
>>>> perspective (lb's,
>>>> reverse caching, memcache, redundant bandwidth, redundant servers,
>>>> etc)
>>> But the app is the hardest to change. It's much easier to change from a
>>> dialup connection to a T-3, for instance.
>> Nobody is saying don't code well or don't follow best practices or
>> have
>> procedures in place. As stated, scalability is not single faceted and
>> the dirth of apps dying on Black Friday or any given successful launch
>> are
>> proof positive of it isn't.
>>
>>>> http://www.ibm.com/developerworks/linux/library/l-tune-lamp- 1/#resources
>>>> http://www.ibm.com/developerworks/linux/library/l-tune-lamp- 2.html?ca...
>>>> http://www.ibm.com/developerworks/opensource/library/os-php- fastapps2/
>>>
>>> Those are good for what they say. But they're by no means complete.
>>> There is a lot more to scaling, even on a single server.
>>>
>> As stated, they are a start, which is far better than you offered. So
>> apart
>>from snide remarks and a complete failure to actually provide
>> something useful,
>> do you actually have anything to add?
>>
>>> So your answer is telling him to google? Gee, can't you do better than
>>> that?
>> Yes, I refer you to the almighty fact that you didn't give him a
>> nickels
>> worth of url he could so much as peruse.
>>
>> Added that given how trivial it is once you get started to google for
>> the rest,
>> he shouldn't have too much of a problem and even be able to come back
>> here and
>> ask questions if he needs.
>>
>> Or he could hire me.
>
> Looks like Jerry's gonna start calling you a troll and a fraud too.
> He's having a very bad week in that respect.
I OWN YOU, Gary. And once again you prove it!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
On Jan 6, 3:04 pm, Jerry Stuckle
> faulkes wrote:
> I've been programming for around 40 years now. I've worked on a lot of
> projects in that time. Those which were not managed well had the
> problems you describe. But those which were well-managed did not.
pretty damn hard to screw up an abacus I guess. I suppose you
helped gore invent the integer as well as the internet.
> Other than the fact you've offered very little other than 3 links he
> could have easily found in google? Big deal.
Pick a side here Jerry, either telling him to google is easy and
effective
or it isn't. The fact still remains you didn't offer jack squat but
seem
to indicate that you *do* know of such sites
> That's because I don't have on particular site. The links you gave were
> OK - but not at all complete.
Which again, implies that you know of somes sites, wouldn't at all
hurt if you
even bothered to paste *1* single link, but no Jerry, that didn't seem
to be the case.
> > Or he could hire me.
>
> Yep, and get an application which will fail as soon as he gives it to a
> user.
Given that you know nothing about me, my skils, abilities or
experience
that's an overly broad assertion. I'd almost say you were trying to
bait
me, unfortunately, your troll-foo is weaker than a mewling kitten.
So, either step and start offering something he can use, or stop
replying
and making yourself look bad.
http://www.howtoforge.com/loadbalanced_mysql_cluster_debian
http://tldp.org/
Look Jerry, two more easy to find links, given freely, see how
easy it is to be constructive?
Post removed (X-No-Archive: yes)
..oO(Gary L. Burnore)
>Looks like Jerry's gonna start calling you a troll and a fraud too.
>He's having a very bad week in that respect.
And you just can't resist to stupidly reply to each and every of his
postings in each and every newsgroup, which makes you as bad as him.
You both are trolling, but obviously not able to realize that anymore.
*plonk*
Micha