Re: Examples of SQL anomalies?

From: Brian Selzer <brian_at_selzer-software.com>
Date: Mon, 30 Jun 2008 18:29:06 -0400
Message-ID: <T6dak.13605$mh5.4857@nlpi067.nbdc.sbc.com>

> "Rob" <rmpsfdbs_at_gmail.com> wrote in message news: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-
> Link 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.

Perhaps you should write more clearly. The paragraphs you mention fall under the heading, "Integration by Structure" in the section following the aforementioned queries and therefore appear to have nothing to do with them. I think that in addition to more practical database courses (or a hellofalot more practical experience, hopefully under a capable mentor), you may want to take a course in technical writing. And by the way, if you already have a degree, you should probably ask for your money back. Received on Mon Jun 30 2008 - 17:29:06 CDT

Original text of this message