Fastest way to get thousands of db records to client in 3 tier?

John J. Lee jjl at
Fri Sep 26 18:14:45 CEST 2003

amonroejj at (R. Alan Monroe) writes:

> In article <874qz22jah.fsf at>, jjl at (John J. Lee) wrote:
> >> >Why not let the client ask directly if it is faster?
> >> I thought that defeats the purpose of having 3 tiers. You'd have to 
> >> update the client if/every time business rules changed. Unless I'm 
> >[...]
> >
> >Why?  The client asks the client in terms of "business logic", the
>            ^^^^^^^^^^^^^^^^^^^^^^
> Not sure what you meant to say here?

The client asks the server, sorry.

> Let's say I want to see all the tickets I worked on in the previous 
> calendar year. The server can get this from the DB in 1 second. But if 
> the server has to spend 30, 60 or more seconds getting those results 
> back to me, the client, the system wouldn't be worth using, in my 
> opinion.

"So don't do that", was the point that somebody was making.  Worry
about the big issue of what network traffic you'll have and how many
round trips, not the small issue of the particular means of transport
of that traffic.

> I _have_ used systems that returned a subset of matching records to 
> the client, and found it very uncomfortable. That's why in my system I 
> want to scratch my own itch, and return all the records.

Fair enough.  Would have to know more to comment.


More information about the Python-list mailing list