DB API

[Gordon McMillan]

Aahz wrote:
> Boudewijn Rempt <boud at rempt.xs4all.nl> wrote:
> >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. 
> 
> Uh, if it's a properly constructed database, it shouldn't get tied up
> like that.

Perhaps some bozo code "FOR UPDATE" in the select 
statement? <sound of fingers breaking>. He won't do that 
again.

Actually, if the SQL is coded right (no ORDER BY or GROUP 
BY) and the stuff in the middle is decent, the DB can be 
returning rows before the query has even finished executing. If 
the query is parameterized (pre-parsed) and simple, the 
bottleneck will be the network and the load on the DB will be 
insignificant. Unfortunately, that's a lot of "if"s...
 


- Gordon