Use of the term "hierarchy"

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Thu, 25 Aug 2005 20:07:39 -0400
Message-Id: <l132u2-jg1.ln1_at_pluto.downsfam.net>

Generally speaking, we seem to use the word hierarchy to mean a situation where a table has a foreign key to itself (or a child table has two foreign keys to the same table that are non-transitive), with the usual assumption that nesting could go to any level and that the levels are indistinguishable from each other.

We don't tend to say hierarchy when referring to the structure of related tables, such as Jobs -> Orders -> Order Lines. This always looked like a hierarchy to me though. It is a hierarchy of unlike items, in which the allowed relationships of parent/child are determined by table structure.

So if we have hierarchies of unlike items and then those of like items, it seems we may mistake one for the other.

Consider the canonical example of employees and their supervisors. This is usually presented as a hierarchy of like items. 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.

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.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)

Received on Fri Aug 26 2005 - 02:07:39 CEST