Re: VIEWS compared to Nodes as Windows into data

From: x <x-false_at_yahoo.com>
Date: Tue, 4 May 2004 13:36:17 +0300
Message-ID: <4097716b$1_at_post.usenet.com>


  • Post for FREE via your newsreader at post.usenet.com ****

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c75vlp$160$1_at_news.netins.net...
> "x" <x-false_at_yahoo.com> wrote in message
news:40967812$1_at_post.usenet.com...
> > **** Post for FREE via your newsreader at post.usenet.com ****
> > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > news:c75rev$tdq$1_at_news.netins.net...

> > What do you mean by "performing the join" or "the join get executed" ?
:-)
> > When Pat query against G, she gets what she was asking for .

> First, for clarity, let's restrict this to a question about SQL, not about
> relational operators in general. Additionally, since each implementation
of
> SQL is different, I'm thinking of the best commonly used implementation of
> SQL for this question (I don't know which one, but Oracle, DB2, and SQL
> Server are certainly in the commonly used category).

>

> An example (at the risk of inviting issues that are not germane):
>

> PERSON: (PersonID, FirstName, MaritalStatusAbbreviation)
> MARITALSTATUS: (MaritalStatusAbbreviation, Description)
> ORDER: (OrderID, PersonID, OrderDate)
>

> Create a View that results in the same as this one:
> CREATE VIEW PERSONVIEW AS SELECT * FROM PERSON, MARITALSTATUS, ORDER WHERE
> ORDER.PersonID=PERSON.PersonID AND
> PERSON.MaritalStatusAbbreviation=MARITALSTATUS.MaritalStatusAbbreviation;

Please think what the "view" would look like if you "normalize" the relation PERSONVIEW.
This "view" is equivalent with the view in the "navigational" approach ? Are you comparing apples with apples and oranges with oranges ?

> Now do a query against that view:
> SELECT FirstName, OrderID FROM PERSONVIEW;

> Is the MARITALSTATUS table ever accessed when doing this query against
that
> view? What if MaritalStatusAbbreviation in the PERSON table can be NULL?
> Does SQL recognize when it needs to and when it does not need to perform
> this join?:

What do you mean by "TABLE EVER ACCESSED" ? THAT TABLE DOES NOT EXIST !
As I said Relational is just a language.

> > What atomic operations would be "executed" by the DBMS in
> > the two scenarios/DBMSs you have in mind ?
>
> Does the previous example clarify that?

No. It doesn't.
Think about LANGUAGE TRANSLATION (compilers vs. interpreters).

Do you think is possible to make a translator from Relational (or SQL) to "navigational" ?

By "atomic operations" I mean the operations implemented on the main memory/disk
data structures.

> > Why there would be more operations for a RDBMS than for any other DBMS ?
> > As I said "Relational" is just a language.

>

> If a view of the data is not the result of a join operation, but of
> navigation and then a field is not requested in the query, there is no
need
> to involve such navigation.

Are you comparing apples to apples ?
Are you comparing "logical join" to "logical navigation" ? Is this comparation relevant for the performance of a DBMS ?

> > > But do current RDBMS's figure out when they don't need to include the
> join
> > > bz they know (how?) that the join will not result in a different row
set
> > and
> > > there are no attributes from table G in the query against the view?
> >
> > There is a current RDBMS ? :-)
> > If Pat asked for the join, an RDBMS would need to consider it.
> > If Pat haven't asked for a field from table G, then an important
> > part of the join may be skipped.
> > Sometime the other part of the join can be skipped too. ;-)
> >
> > It is called query optimization.
>
> Yes -- does SQL do the type of optimization in the example above where
they
> would ignore a table in the view when it was not required?

I think now you have an idea on how this is done.

> The abstraction part of this question relates to the number of "portals
into
> the data" that are required for any particular user and I don't know if I
> have the facts clear related to how SQL works. Then stepping up from
that,
> it is not a SQL issue, per se, if this is not optimized, but an issue of
> using set-processing operations rather than, for example, tree navigation
> operations, when preparing "views" or windows into the entire set of data.

Think about an Relational (or SQL) SCHEMA as "portals into the data". I think that the name VIEW in SQL for a named derived relation (or relvar) is misleading.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  • Usenet.com - The #1 Usenet Newsgroup Service on The Planet! *** http://www.usenet.com Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Received on Tue May 04 2004 - 12:36:17 CEST

Original text of this message