Re: Nested Sets vs. Nested Intervals

Mikito Harakiri wrote:
> DonR wrote:
> > dawn wrote:
> > > michael_at_preece.net wrote:
> > > > I can't understand why no one has suggested Pick for this. Seems
> > > > perfectly simple to me. Anyone who has used Pick would not think twice
> > > > about this. The solution to the OP's problem would be trivial in the
> > > > extreme.
> > >
> > > Of course you are right, Mike. smiles. --dawn
> >
> > Micheal and Dawn,
> > I see the folks here just ignored the Pick suggestion. This has always
> > been Pick's problem, the guru's think things have to be complicated to
> > work.
> > Of course, if they were using Pick, they wouldn't need to be on here
> > discussing meaningless theory.
> >
> > I've worked with Pick for 20 years and haven't found a business problem
> > that Pick couldn't handle.
>
> Hmm, i thought that Pick, XQuery and others are still trying to figure
> out how to solve this
> "Find all the employees who earn more than their managers"

No problem for PICK. Because virtual fields can be written with query language constructs and/or DataBASIC (likely the best implementation based on Dartmouth BASIC ever written), there is no problem answering such questions. The ease of use with the query language is part of the charm of PICK, while it is not at all part of the charm of XQuery (if you ask me). This is accomplished by setting up the vocabulary for the user, however, and behind some of that vocabulary might just be some procedural code.

In this old query language that has a ton of names, none of which is generic (see my poster of the MultiValue Family tree at http://www.tincat-group.com/mv/familytree.html to get the list of names down the right hand side in case you want to know if you have ever encountered it), the queries are against a single view/vocabulary/dictionary/file.

A PICK-like query for your example would look like:

SELECT EMPLOYEES WITH ANNUAL_SALARY > MANAGER_SALARY [Notice that entity names are often plural so the queries sound quite English-like, with ENGLISH being one of the names for this language]

There are never joins or compound queries. There is no such thing as a base table (or else everything could be considered such). EMPLOYEES as a strong entity is modelled as a file, and annual salary might be a stored data attribute or field in that file. Manager salary would be derived data or a "virtual field" associated with this same file, but tracing the graph from this node to the manager node and then picking off the stored salary data there. This example would obviously not require any procedural code since it is simply node hopping, but a virtual field like MANAGER_YTD_PAY in the EMPLOYEES vocabulary/dictionary list would likely have a subroutine backing it to aggregate from detail records.

I hope that made sense. XQuery as a language for a human being to employ to query data doesn't hold a candle to the PICK query language. But given a raw schema for stored data only and the PICK query language, you get nowhere since you can only see through the lens of one file/dictionary with any query. You can write some virtual fields on the fly within the query language, but not enough to cover.

Cheers! --dawn Received on Thu Nov 17 2005 - 04:26:07 CET