Re: Location Structures Approaches, Pros & Cons

From: Mark Johnson <102334.12_at_compuserve.com>
Date: Fri, 24 Feb 2006 17:41:34 -0800
Message-ID: <bedvv15jkl93h1qj9shbi125ojqd4tl5rf_at_4ax.com>


Tim Marshall <TIMMY!_at_PurplePandaChasers.Moertherium> wrote:

>Mark Johnson wrote:

>One way pointer? Are you telling me that parent child relationships
>within a table are something one should not do?

I'm saying it's something that those who insist that the table IS a relation, rather than something based on it, would say violates the rules.

>establish a hierarchy between items that are the same data entity, for
>example, say in an equipment table in which a motor is a child of an air
>handling unit or fan and an on/off switch is a child of that motor?

And parts lists are a typical example, because you don't know what the next subcategory will be, or if the vendor or client start moving everything around. It's tedious, but can be accomodated with just manual drag n drop in a tree-view listing. Rearranging tables to account, not merely adding some in addition, and removing others, might actually seem more error-prone, even if whatever updates were required were left to SQL queries, and ought to be in any case.

I'm not saying - don't do it. I would suggest most everyone uses such tables. It's an accomplished fact. I'm just saying that in doing this, it goes against the theory which supposedly lies behind these various commercial databases. And it introduces problems of its own, potential errors which the same folks would eagerly warn against, and without an explicit path for each node, is dependent on the efficiency of the implementation of chain/link reconstruction by something like Connect By, or whatever is on your system. It just becomes a practical consideration as to whether once the dataset reaches a certain bulk, if retrieval becomes prohibitively slow, as one important consideration. Retrieval delay. But in particular if this is a database that is not used to generate oddly structured reports, or which would have to retrieve a lot of data on a regular basis, but where the consideration is more entry and inserting the information just as archive, then perhaps even that wouldn't pose a problem. Received on Sat Feb 25 2006 - 02:41:34 CET

Original text of this message