Re: Use of the term "hierarchy"
From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Mon, 29 Aug 2005 07:37:28 -0400
Message-Id: <5j8bu2-qt4.ln1_at_pluto.downsfam.net>
>
> The concern I have with this idea is that is has so much
> in the way of non-local effects. One is pulling in data
> from essentially the entire namespace. It's not clear to
> me that one wants to have the requirement that the
> namespace be fully unified; that every "employee" attribute
> has to mean the same thing. Scope is a good thing.
>
> Also a non-local effect: the creation of a new table with
> the appropriately-named attributes changes the meaning
> of this query. It's essentially implicitly dependent on the
> entire schema. That's hard to control.
>
>
Date: Mon, 29 Aug 2005 07:37:28 -0400
Message-Id: <5j8bu2-qt4.ln1_at_pluto.downsfam.net>
Marshall Spight wrote:
>> >> 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 concern I have with this idea is that is has so much
> in the way of non-local effects. One is pulling in data
> from essentially the entire namespace. It's not clear to
> me that one wants to have the requirement that the
> namespace be fully unified; that every "employee" attribute
> has to mean the same thing. Scope is a good thing.
>
> Also a non-local effect: the creation of a new table with
> the appropriately-named attributes changes the meaning
> of this query. It's essentially implicitly dependent on the
> entire schema. That's hard to control.
>
>
When you have completely disambiguated your query you are back to conventional SQL.
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Mon Aug 29 2005 - 13:37:28 CEST