Re: Use of the term "hierarchy"
From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Mon, 29 Aug 2005 12:56:36 -0400
Message-Id: <h9rbu2-096.ln1_at_pluto.downsfam.net>
>
> Interesting!
>
> I'm still a bit skittish about the idea of "seach" within
> a schema, but this example puts a different light on it.
>
>
Date: Mon, 29 Aug 2005 12:56:36 -0400
Message-Id: <h9rbu2-096.ln1_at_pluto.downsfam.net>
Marshall Spight wrote:
>> >> It seems the whole point of an invented table-column-oriented query is to >> search in a wider scope, no? If you don't want that then narrow the >> scope: >> >> Select *.employee >> FROM (table1, table2, table) >> WHERE project_start < '2005-11-15' >> >> When you have completely disambiguated your query you are back to >> conventional SQL.
>
> Interesting!
>
> I'm still a bit skittish about the idea of "seach" within
> a schema, but this example puts a different light on it.
>
>
Methinks it is OK if there are determistic rules about what will be returned, and if the server rejects a query it cannot disambiguate. So if three tables have "project_start" in them and also "employee" (assume same name=same thing) then an examination of foreign keys ought to determine when to UNION or JOIN. Perhaps this version:
Select Meta.Table_name,*.employee,*.project_start WHERE project_start < '2005-11-15;
would return also where the data came from. An EXAMINE function would show the complete query tree.
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Mon Aug 29 2005 - 18:56:36 CEST