Re: [dba-users] Queries in Queries

Mon, 24 Apr 2006 06:55:33 -0700

Frank Schönheit - Sun Microsystems Germany wrote: 
Hi Andrew,

  
It seems obvious to me that having a query as part of a query
is just a matter of making the parser accept sub-selects.
    

Not completely. "Stored" sub selects (be it as view or as query) have
the advantage that they can be edited independently from the "outer"
query, and re-used in different other queries. Especially the latter is
an important facet of the whole feature, which I think we don't want to
lose.

Ciao
Frank
Ok, I think I am just doing a decidely poor job of explaining myself.

What I am trying to point to is this.

If a query is just a container for a select statment, then the parser could use that named container in its peresentation to the user. At runtime however, prior to issuing the statement to the engine the container would be expanded to the select statement it holds.

So, using my example from before I create a query named qryAddresses. It contains the statment
SELECT * FROM "tblAddresses".

If then create a second query that used qryAddresses it would be presented to the user as 

SELECT
    "tblNames".*,
    "qryAddresses".*
FROM
    "qryAddresses" "qryAddresses",
    "tblNames" "tblNames"
WHERE ( "qryAddresses"."NameID" = "tblNames"."ID" )

But at runtime it must be exanded to 

SELECT
    "tblNames".*,
    "qryAddresses".*
FROM
    ( SELECT * FROM "tblAddresses" ) "qryAddresses",
    "tblNames" "tblNames"
WHERE ( "qryAddresses"."NameID" = "tblNames"."ID" )

and then passed to the engine. The basic idea is the same as what is done with parameter replacement now.

The user is still free to go back to the defintion of qryAddresses and alter it - use it alone, add it to another query, whatever.

I really should have said - It seems obvous to me that supporting sub-selects in the parser is the first step in being able to support queries in queries.

Reply via email to