<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Sep 29, 2007, at 19:35, K J wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>Currently I only store the vote score in the comment itself. You are saying I should store it in the comments listing too?</DIV><DIV> </DIV><DIV>I might give that a try, and do the comment filtering in the php app instead.</DIV></SPAN></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>Doing so means that your representations of your data are always accurate, but at a reasonably low cost.</DIV><BR><BLOCKQUOTE type="cite"><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>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. </DIV><DIV> </DIV><DIV>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.</DIV><DIV> </DIV><DIV>Would this type of situation warrant what I was suggesting?</DIV></SPAN></BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>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. :)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>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. </DIV><BR><DIV> <SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>-- </DIV><DIV>Dustin Sallings</DIV><BR class="Apple-interchange-newline"></SPAN> </DIV><BR></BODY></HTML>