By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,654 Members | 1,840 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,654 IT Pros & Developers. It's quick & easy.

best approach to caching DB results

P: n/a

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...
Jan 5 '08 #1
Share this Question
Share on Google+
14 Replies


P: n/a
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.
js*******@attglobal.net
==================

Jan 5 '08 #2

P: n/a
On Jan 4, 6:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
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.
Jan 5 '08 #3

P: n/a
On Jan 5, 5:13 am, flowover <flowover...@gmail.comwrote:
On Jan 4, 6:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
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.
Jan 5 '08 #4

P: n/a
flowover wrote:
On Jan 4, 6:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>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.
js*******@attglobal.net
==================

Jan 5 '08 #5

P: n/a

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).

Jan 6 '08 #6

P: n/a
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.
js*******@attglobal.net
==================

Jan 6 '08 #7

P: n/a
On Jan 6, 1:45 am, FFMG <FFMG.32r...@no-mx.httppoint.comwrote:
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/li...p-1/#resources
http://www.ibm.com/developerworks/li...01LAMPTuningP2
http://www.ibm.com/developerworks/op...php-fastapps2/

Those should cover your basics of the single server and php, google
the rest out
for load balancing, caching, etc.
Jan 6 '08 #8

P: n/a
faulkes wrote:
On Jan 6, 1:45 am, FFMG <FFMG.32r...@no-mx.httppoint.comwrote:
>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/li...p-1/#resources
http://www.ibm.com/developerworks/li...01LAMPTuningP2
http://www.ibm.com/developerworks/op...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.
js*******@attglobal.net
==================

Jan 6 '08 #9

P: n/a
Gary L. Burnore wrote:
On Sat, 05 Jan 2008 09:05:49 -0500, Jerry Stuckle
<js******@attglobal.netwrote:
>flowover wrote:
>>On Jan 4, 6:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
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.
js*******@attglobal.net
==================

Jan 6 '08 #10

P: n/a
On Jan 6, 1:39 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
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/li...p-1/#resources
http://www.ibm.com/developerworks/li...lamp-2.html?ca...
http://www.ibm.com/developerworks/op...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.
Jan 6 '08 #11

P: n/a
faulkes wrote:
On Jan 6, 1:39 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>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/li...p-1/#resources
http://www.ibm.com/developerworks/li...lamp-2.html?ca...
http://www.ibm.com/developerworks/op...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.
js*******@attglobal.net
==================

Jan 6 '08 #12

P: n/a
Gary L. Burnore wrote:
On Sun, 6 Jan 2008 11:17:45 -0800 (PST), faulkes
<mi*************@gmail.comwrote:
>On Jan 6, 1:39 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>>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/li...p-1/#resources
http://www.ibm.com/developerworks/li...lamp-2.html?ca...
http://www.ibm.com/developerworks/op...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.
js*******@attglobal.net
==================

Jan 6 '08 #13

P: n/a
On Jan 6, 3:04 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
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/loadbalanc...cluster_debian
http://tldp.org/

Look Jerry, two more easy to find links, given freely, see how
easy it is to be constructive?
Jan 6 '08 #14

P: n/a
..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
Jan 7 '08 #15

This discussion thread is closed

Replies have been disabled for this discussion.