On Sep 29, 2007, at 19:35, K J wrote:
Currently I only store the vote score in the comment itself. You
are saying I should store it in the comments listing too?
I might give that a try, and do the comment filtering in the php
app instead.
If the comment scores are changing independently, you can store them
independently. You could, for example, make them counters. The same
request that's asking for the article keys can include a request for
the counter keys as well.
Doing so means that your representations of your data are always
accurate, but at a reasonably low cost.
There are some other examples though, where it gets really
expensive to re-calculate on every change. For instance search
results. If just one item's attributes change (which happens
probably once every 10 seconds), a whole range of search queries
would be invalided.
Take for example, Myspace's browse page. There are multiple
options you can select, such as age, zip code, sex, etc. Just
having one user change his zip code would invalidate all the
combinations that involve the zip code. If the site is busy,
invalidations could be occurring every few seconds, putting lots of
load on the server. Then, at night when there's little traffic,
hardly any updates are happening.
Would this type of situation warrant what I was suggesting?
I suppose that it's possible depending on the design. The semantics
sound similar to flush with respect to the delay mechanism. It does
make more sense to me than flush in that case, although that's not
saying a lot. :)
It does have a bit of a ``just don't do that'' feel, though. Most
search engines seem fast enough that you wouldn't necessarily bother
caching their results.
--
Dustin Sallings
