Re: Use of the term "hierarchy" (and table/class)

Alexandr Savinov wrote:
> ... One aspect of this problem could be formulated
> as follows:
>
> - when to represent a thing by normal record/row/object or by table/class

Why lump data-only things (record, rows) and a mixture of data and behaviour (object) together? The table/class mix-up even more error-prone: earlier mistakes lead to bigger messes.
Even struts users are starting to realise that.

The question wether to represent a thing in data at member or set level depends on our information needs regarding those things, not on preconceived structures.

[snip]
> First of all we distinguish two types of structures in the model:
> - physical structure which is purely hierarchical (tree-like) with one
> root, which consists of concepts, which in turn consist of data items, and

The hierarchy here is for a great deal in the 'we distinguish', not only in the physical structure per se.

> - logical structure where each element (concept or item) may have a
> number of parents and a number of children

Which leads to heterarchies - only when children are restricted to have only one parent whe have hierarchies, that is when 'number of parents' is always one.

> This has several consequences:
> - we can consider concepts and items in one space (within one physical
> structure) so they are not isolated elements of the model
> - with more levels in the physical structure we can introduce a physical
> hierarchy with more level, for example, tables consist of partitions
> which consist of records. Another application is a mark-up language.

Sure there are more levels in the physical structure - but tables are not physical. A table is one way of representing data.

> - hierarchy between physical elements of higher level (say, tables)
> impose constraints on its child elements (say, records)

Lower level constraints may also propagate to constraints on higher levels.

> - this allows us to clearly separate two concerns: physical structure
> and logical structure. It is a consequence of more general (theoretical)
> principle that any element consists of two parts: a collection of other
> elements, and a combination of other elements.

I think there is an important distinction here but the phrasing doesn't really help me focus on it. Received on Sat Aug 27 2005 - 01:01:00 CEST