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...
14  1752 
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
==================
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.
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.
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
==================
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
==================
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.
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
==================
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
==================
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.
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
==================
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
==================
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?
..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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: John J |
last post by:
I've written the following code into a class to search for and display the
results of all races entered (The complete code is in a previous thread). I
wish to amend the code so as to display the...
|
by: PWalker |
last post by:
Hi, I have written code that I would like to optimize. I need to push it to
the limit interms of speed as the accuracy of results are proportional to
runtime.
First off, would anyone know any...
|
by: Matt Kruse |
last post by:
http://www.JavascriptToolbox.com/bestpractices/
I started writing this up as a guide for some people who were looking for
general tips on how to do things the 'right way' with Javascript. Their...
|
by: Duncan Welch |
last post by:
Good morning,
I have a classic ASP app that I'm converting to .NET. In the existing app
when accessing infrequntly changed data, it reads a database once a day, and
saves the results in an...
|
by: Ken Varn |
last post by:
Is there anyway within my web application that I can have all browser
caching turned off for all aspx pages sent by my IIS server? I need to have
all caching off in order for certain things to...
|
by: Marc Gravell |
last post by:
Kind of an open question on best-practice for smart-client design. I'd
really appreciate anyones views (preferably with reasoning, but I'll take
what I get...). Or if anybody has any useful links...
|
by: Jeff |
last post by:
For years I have been using VBA extensively for updating data to tables
after processing. By this I mean if I had to do some intensive processing
that resulted in data in temp tables, I would have...
|
by: Rob Meade |
last post by:
Hi all,
I have a databse which I'm pulling the data from for my ASP page.
I have 4 tables, Course, Feature, Objective, and PreRequisite. The last
three all contain a course product code and a...
|
by: Hermann |
last post by:
My site is a bit slow showing the main page so I thought caching query
result in PHP will improve performace.
Then I read MySQL documentation and saw that MySQL does have a caching
feature.
So......
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
