Re: Navigation question

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.

Ewww! Certainly *bad* software does that, but good software doesn't. Part of my job description is smacking noobs who do the above with a large, migratory fish. Salmon is my favorite.

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.

> 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