Re: Performance of count(*)

On 22.03.2007, at 11:53, Steve Atkins wrote:

> As long as you're ordering by some row in the table then you can do
> that in
> straight SQL.
>
> select a, b, ts from foo where (stuff) and foo > X order by foo
> limit 10
>
> Then, record the last value of foo you read, and plug it in as X
> the next
> time around.

This does only work if you have unique values in foo. You might have
"batch breaks" inside a list of rows with equal values for foo.

But: a web application that needs state and doesn't maintain it by
itself (or inside the dev toolkit) is imho broken by design. How
should the database store a "state" for a web app? It's only possible
on the web app part, because the app is either stateless and so are
the queries to the database - they have to be re-evaluated for every
request as the request might come from totally different sources
(users, ...) or it is stateful and has to maintain the state because
only the app developer knows, what information is needed for the
"current state".

This is why all web application toolkits have a "session" concept.

> I think the problem is more that most web developers aren't very good
> at using the database, and tend to fall back on simplistic, wrong,
> approaches
> to displaying the data. There's a lot of monkey-see, monkey-do in web
> UI design too, which doesn't help.

Sure. That is the other problem ... ;-) But, and I think this is much
more important: most toolkits today free you from using the database
directly and writing lots and lots of lines of sql code which
instantly breaks when you switch the storage backend. It's just the
thing from where you look at something.

cug