Re: Navigation question
Date: 14 Feb 2007 11:47:54 -0800
On Feb 14, 7:43 am, "dawn" <dawnwolth..._at_gmail.com> wrote:
> Application software typically reads data from a
> database, takes a foreign key value, and reads in other data.
If you have customers and orders tables, and you want to look at, say, all orders for a given customer with date > 1/1/2006 and status = fulfilled, you could navigate like this:
get customer # 1234
get list of that customer's orders
for each order
get the order
if order date > 1/1/2006 and order status = fulfilled add order to result
If get-customer and get-order run over the network, then this software will perform poorly. However if you have some ad hoc data api, that's probably your only choice. However you would still get a fish-smack from me.
Or you could do this:
select * from orders where date > '2006-01-01' and status =
'fulfilled' and customerid = 1234
You say what you want and you get just that. No sifting
through stuff you don't want; no navigating.
select * from orders where date > '2006-01-01' and status = 'fulfilled' and customerid = 1234
You say what you want and you get just that. No sifting through stuff you don't want; no navigating.
> Do large, production-quality, highly usable and useful, data-based,
> read-and-write software applications actually exist where there is no
> code in the software that navigates around the database?
Sure! They tend to perform well, too, in a multitier environment. All that navigation is *expensive* in terms of network requests. In fact, it is my opinion that *the* single biggest performance win to be had in distributed computing is to minimize the number of network round trips per client request. The best way to do that is to have the highest-level, most declarative way of describing what a request wants to do. A low-level navigational approach will always generate a lot of individual requests, because the client has to issue a lot of requests to navigate through and filter a lot of data.
Marshall Received on Wed Feb 14 2007 - 20:47:54 CET