Re: Nulls, integrity, the closed world assumption and events

From: JOG <jog_at_cs.nott.ac.uk>
Date: 21 Jan 2007 18:57:05 -0800
Message-ID: <1169434625.501164.232880@11g2000cwr.googlegroups.com>

dawn wrote:
> JOG wrote:
> > dawn wrote:
> > > Keith H Duggar wrote:
> > > > dawn wrote:
> > > > > Walt wrote:
> > > > > > Many have attempted, but you have been expounding on the same incorrect
> > > > > > ideas for something like five years now.
> > > > >
> > > > > Could you point me to proof that something I expound is incorrect?
> > > > > Perhaps just starting by telling me what I think to be true that you
> > > > > think false, or vice versa, would be helpful. I would very much
> > > > > appreciate knowing.
> > > >
> > > > RM != SQL
> > > > QED
> > > >
> > > > Keith -- Fraud 6
> > >
> > > Hi Keith - I do not equate RM with SQL. I do think, however, that we
> > > would not have SQL were it not for the RM.
> > > The RM could be seen as a primary "culprit" in giving us SQL.
> > > Additionally, most, if not all, implementations that are based on the
> > > relational model employ SQL as the means of interacting with the DBMS.
> > > Marketing and other materials for a couple of decades now use the
> > > acronym RDBMS when referring to SQL-DBMS's for good reason.
> > > [snip]
> >
> > It is not that you confuse RM with SQL.

>

> Good, because I have heard that a number of times, and I did not think
> it to be the case.

>

> > It is that because RM doesn't
> > do everything you want

>

> I don't even think of it as "doing" anything, but as "being" so that
> might be a problem.

>

> > (and only an idiot would think that the RM is
> > the last word in data management),

>

> Agreed. For a couple of decades it dominated in the world of database
> buzzwords, however. That is only starting to change (perhaps) very
> recently.

>

> > you promote throwing the baby out
> > with the bath water,

>
> I can think of a few things I would throw out (the three I mentioned).

This is RM != SQL again. You stated that only _one_ of the three was relevant to the modern view of RM, but you now want to throw out three - this is illogic.

> I don't know if those are what you are calling "the baby"

No pointers. No dependence on manual navigation. Thinking in terms of propositions not objects. Essentially the information principle. We must not lose the invaluable insights if we are progress to even better techniques.

> or if it is
> related to my questions (and not fully developed opinions) on typing,
> metadata as data (related to DBMS constraints or lack thereof), or
> additional functions, such as navigation, in addition to set-based
> functions.

Functions on datatypes are external to the underlying algebra. So again not part of the RM, and can be happily part of a DBMS.

> I do not throw out relations nor functions on them, but I
> do favor also talking about relations as functions, since I have rarely
> (if ever) worked with relations that are not in data-based software
> development.

A db-tuple is mathematical function. A db-relation is a commonly structured set of these functions.

>

> > and losing all of the invaluable insights that
> > Codd brought.

>

> I definitely do not want to make the same mistake made by some who
> started with the RM around '70 or thereafter and dumped the wealth of
> best practices in data-based software development that preceeded it.

I cannot comment on pre-1970's. I came to data theory much later, whence 20 years of addtional good practices had been developed.

> I have an appreciation for relations and set-based functions. I
> understand how elegant it is if we can add (at least some) constraints
> in as propositions in the schema. But if you are talking about 1NF or
> 3VL, for example (and I do not know what you are referring to when
> suggesting I am losing all such insights),
> while I can appreciate the
> simple elegance of 1NF, it would be fair to say that any elegance in
> the use of 3VL is lost on me. I am quite sure I'm not alone in that
> regard, however.

No 3VL, of course not. I would comment on 1NF but I get confused as to whether you are referring to 1NF as it is currently viewed in the theory, or as the retro-1NF definition of the early 1970's that you often use (and yes I understand that this is still an SQL-ism in industry).

>

> > This is also why you generate such resentment Dawn.

>

> Only here. I did not realize when I started asking questions (which I
> do by stating opinions and finding out what I'm missing) that this was
> perceived by most as a forum for relational theory alone. Live and
> learn, eh?

Frustration is generated more easily in written media, wand one should always be aware of that - (and especially if one has no theories to offer on a theoretical forum.) For example the above would frustrate many as it appears to be baiting again, knowing full well that a lot of what is discussed here is outside of relational theory. However it does have to be /theory/ of some sort.

>

> > Saying RM != SQL is just shorthand for that I think.

>

> It is inaccurate, however, so thanks for recognizing that. Although
> your explanation was helpful, it did not exactly point me to what it is
> that I seem to believe that is not the case. What I think might be the
> case, however, is the fact that one of the buzz words that I decided
> has been harming software development productivity is "relational" as
> in "relational databases" and "relational model." The adoption of this
> buzzword and related implementations is what dealt an
> almost-but-not-quite death blow to models such as MUMPs (now quite
> alive in Cache') and PICK (also still alive, now in Cache' as well as
> IBM U2. I am starting to think that if I held most of the opinions
> that I have reached but did not at the same time try to knock out the
> "relational" term as king-of-the-hill, I might not have incited some
> here unnecessarily.

>
> cheers! --dawn

These are just my opinions, for whatever they are worth. I believe people at the coal-face of db's have a lot to offer in terms of empirical evidence. However it is very easy to confuse problems of interfacing, impedence and insufficient tools, with theoretical weaknesses (especially if one is using a poor implementation of that theory). Received on Sun Jan 21 2007 - 20:57:05 CST