Re: Demo: Modelling Cost of Travel Paths Between Towns

From: Nick Landsberg <SPAMhukolauTRAP_at_SPAMworldnetTRAP.att.net>
Date: Mon, 15 Nov 2004 03:15:21 GMT
Message-ID: <dbVld.20764$7i4.20510_at_bgtnsc05-news.ops.worldnet.att.net>


Neo wrote:

>
>
> The distinguishing characteristic of a hierarchal model is that a
> thing can only have one parent. Each thing in TM/XDb2 can have any
> number of relations (of any number of types) to any number of other
> things. Try implementing www.xdb2.com/example/ex113.asp with any data
> model you know. None are as flexible/generic as TM/XDb2.

Let's take a textbook example, Neo.
Let's say I have a database of machine parts, each of which has possibly many suppliers.

Nut - 0.5 cm, standard thread, is supplied by N suppliers. Bolt - 0.5 cm, standard thread, is supplied by an intersecting set of M suppliers.

Each supplier may supply more than one size of nut or bolt.

Let's say I need to execute the following queries:

  • List all the suppliers that supply 0.5 cm bolts. (Easy, depending on how you define the hierarchy.)
  • List all suppliers that supply 0.5 cm nuts. (Easy)
  • List all suppliers that supply both. (Easy)
  • List all the bolt and nut sizes supplied by supplier "X". (Harder ... is the hierarchy by nut and bolt sizes or by suppliers? As I said, this is a textbook exercise. Difficult in a strictly hierarchical model, simple in RM.)
  • List all the suppliers who supply bolt and nut sizes between 0.5 cm and 2.5 cm inclusively. (Harder still in your scheme. Simple in RM).
  • List all nut and bolt sizes supplied by suppliers "X", "Y" and "Z"

If you can do all of these without doing a full scan of the database at least once with your scheme, then you're on to something.

Remember, tho, that real-life databases involve disk reads for data which cannot be easily cached into memory. Some folks work on a 48 GB main memory machine which has about a 1.4 Teratyte disk farm. (That's small nowadays, too.)

NPL

-- 
"It is impossible to make anything foolproof
because fools are so ingenious"
  - A. Bloch
Received on Mon Nov 15 2004 - 04:15:21 CET

Original text of this message