Re: Examples of SQL anomalies?

From: Rob <rmpsfdbs_at_gmail.com>
Date: Mon, 30 Jun 2008 13:58:38 -0700 (PDT)
Message-ID: <57cfcee6-ef66-41b5-8b0a-a19e8dae4575_at_d77g2000hsb.googlegroups.com>


On Jun 29, 9:55 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "Rob" <rmpsf..._at_gmail.com> wrote in message
>
> > I am interested to see if anyone else finds any merit in the
> > relationship-oriented
> > approach.
>
> I think you've missed what underlies the Relational Model.  If attributes
> from two different relations share the same domain and can share some of the
> same values from that domain, then there is an implicit relationship between
> those relations--in other words, if two relations can be joined on a common
> attribute or set of attributes, then there is already a relationship between
> those two relations.  Referential constraints simply describe its character.
> Database schemata with some more complex referential constraints can be
> simplified--that is, replaced by a schemata that includes an additional
> junction relation and simpler referential constraints, but ultimately, the
> junction relation along with the simpler referential constraints boils down
> to just a more complex description of a single relationship.  I just can't
> see any practical use for reifying descriptions of relationships.
>
How about the lattice relationships? Simplification?

Not using these in your current databases? Duh?
>
>
> On the fasttrack page you speak of breaking up the query processing for
> Query 3 into two separate queries and then evaluating them in sequence.  If
> you can't see the problem with that, then perhaps you should go back to
> school.  (Hint:  Suppose an update by another user changes a row in A
> between the select into in Query 4 and the selecct in Query 5.)  Just that
> causes me to question whether your idea merits consideration.- Hide quoted text -
>
You are correct. I thought I mentioned that:

"The scenario of both the logical data- and structure components residing in the same physical database corresponds to "Using Aggregate-  exclusively in OLTP databases" (above). Without this co-location, referential integrity and therefore OLTP databases are not possible. However, for OLAP databases and analytic applications in general, the absence of referential integrity is not critical."

Further:
"In effect, we can construct a virtual OLAP database that spans multiple OLTP databases. All structure relations resides on a single server, entity relations reside anywhere. Entity updates are prohibited, structure updates are allowed. (If you allow entity updates, these are carried out remotely with no overarching transaction mechanism.) "

Before you criticize, perhaps you should read the whole page.

Rob Received on Mon Jun 30 2008 - 22:58:38 CEST

Original text of this message