DB API

[Boudewijn Rempt]

Aahz Maruch <aahz at netcom.com> wrote:

> Oh, okay.  Let's suppose, for example, that you have a customer
> database, and the client wants to view the entire order history for a
> customer.  Would you say that it's inappropriate for the database to
> return thousands of rows for an active customer?

Well, it is if the customer is one of many who expects lightning
performance. If the customer wants a lot of data he will have to wait,
and he will simultaneously tie up the server for other customers. If
he's seriously going to look at thousands of records, well, so be it
then. But it remains a fact that what a database is best at is selectively
presenting a bit of data out of a large mass. If your relational database
is mostly employed serving up most of its contents every query, something
is wrong, and you will get the blame for its lacklustre performance.

Even so, in most cases I've seen, when thousands of rows are retrieved
there's designers/developers laziness or ignorance behind it - and in
most of the other cases the customer can be 'educated' in wanting a more
selective result. Nobody is going to eyeball more than a few hundred
records, and if they are going to post-process the result it is often
better to do the post-processing on the server and send out the result.

> Similarly, suppose you have millions of BLObs that change regularly.
> How would you organize them on an HTTP server?  Incidentally, HTTP is
> *not* an efficient transmission mechanism (less true if you're using
> HTTP 1.1).

If you have millions of large blobs you will have problems no matter
what - nothing I can say or do can worsen or lighten those ;-). I'm not
sure that I know the right solution to problems like that. I know of a
few sites where they regularly work with data like that, but they don't
store it in a relational database, they use custom solutions, and still
often store the blobs on the filesystem.

I know http isn't that efficient, but it allows you to a) offload the
demand to other servers very easily, and  b) present the textual data
already while the customer is still waiting for the picture. 

Anyway, while interesting, this is getting away from Python more
and more...

-- 

Boudewijn Rempt  | http://www.xs4all.nl/~bsarempt