Re: Use of the term "hierarchy"

Alexandr Savinov wrote:

>
> The same can be said about columns (dimensions). We cannot easily work
> with them if information is represented in this way. Just like in many
> cases we need to represent entities by tables, we need also to represent
> something in columns. A simple (I do not say good) example is where one
> column stores sales for one month. If the sales were represented in
> records we could easily apply our powerful query language. But if for
> some reason they are stored in columns then we need to process the data
> manually.
>
> Again, I did not say that we really need
>
> 1. table-oriented modeling facilities and query language, and/or
> 2. column-oriented modeling facilities and query language.
>

Hmmmm, does this qualify:

SELECT *.employee
  WHERE project_start < '2005-11-15'

the the table-column-oriented system infers that you mean to pull and UNION the results from all tables having columns employee code and project_start?

The system should also figure out if a column with some other name is a foreign key to the employees table and so include and use that.

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