Re: Use of the term "hierarchy"
From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sun, 28 Aug 2005 19:14:46 -0400
Message-Id: <h2t9u2-38l.ln1_at_pluto.downsfam.net>
>> It seems however that we do this only because it is
>> far too much bother to store and keep up-to-date
>> the actual structure of a corporation in tables. But in fact, if it were
>> possible to change tables as often as corps change org structures, we
>> would most accurately keep records by having a table of vp's, a table of
>> directors, table of managers, and so forth. Positions would be defined
>> independently of personnel, and one (or more) people could be put into
>> any
>> particular position. Positions have salary ranges or potential legal
>> differences, plus being salaried vs. hourly, union vs. non-union and so
>> forth.
>
> Why 'would' and 'could'? There are a lot of databases designed this way.
>> The common storage of email into nested folders is I believe another
>> example of where a fixed structure of threads and cross-references would
>> likely be far more helpful than the very limited nested folders.
>>
>> OTOH, a bill of materials appears AFAICT to be a true hierarchy of like
>> items, where there are no discernible properties that would give value to
>> different tables for "level 1" "level 2" and so forth.
Date: Sun, 28 Aug 2005 19:14:46 -0400
Message-Id: <h2t9u2-38l.ln1_at_pluto.downsfam.net>
mAsterdam wrote:
>
>> It seems however that we do this only because it is
>> far too much bother to store and keep up-to-date
>> the actual structure of a corporation in tables. But in fact, if it were
>> possible to change tables as often as corps change org structures, we
>> would most accurately keep records by having a table of vp's, a table of
>> directors, table of managers, and so forth. Positions would be defined
>> independently of personnel, and one (or more) people could be put into
>> any
>> particular position. Positions have salary ranges or potential legal
>> differences, plus being salaried vs. hourly, union vs. non-union and so
>> forth.
>
> Why 'would' and 'could'? There are a lot of databases designed this way.
...and there are a lot that are not. And the textbook examples and the discussions in the NG assume a hierarchy of like items.
>
>> The common storage of email into nested folders is I believe another
>> example of where a fixed structure of threads and cross-references would
>> likely be far more helpful than the very limited nested folders.
>>
>> OTOH, a bill of materials appears AFAICT to be a true hierarchy of like
>> items, where there are no discernible properties that would give value to
>> different tables for "level 1" "level 2" and so forth.
> > Not sure if I get this the way you mean it. Let's try: > The level is not a fixed thing in a BOM. Parts of identical type > may have a level depending on the structure they are contained in. > (e.g. knobs in a modular hifi set vs. the same kind of knobs in an > integrated set).
That's what I mean.
I also mean that no accuracy is added by enforcing a fixed nesting level to the hierarchy, such as ten levels, while accuracy is added if you create a fixed number of levels in an org chart.
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Mon Aug 29 2005 - 01:14:46 CEST