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

JOG wrote:
> 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.

No, it isn't. The 3 I bring up all came as a result of the RM, from implementations based on the RM. There are RM-advocates who hold to each of the things I'd like to throw out and think they are doing so because of the RM. The fact that there are different opinions among RM folks is hardly surprising. So, I don't know when you said that I throw the baby out with the bath water if you are referring to any of those three or not.

> You stated that only _one_ of the three was
> relevant to the modern view of RM,

I learned that there are more recent opinions regarding the RM that do not connect 3VL or the form formerly known as 1NF with the RM. That doesn't mean that everyone thinks of them as being outside of it. I did figure that you were considering 1NF and 3VL as bath water, so I wasn't sure whether the baby was the other or something else.

> but you now want to throw out three
> - this is illogic.

I want to toss out all three of these things that have traditionally been associated with RM and have been implemented by those intending to do implemetations of the RM. I am encouraged to find out that others agree on at least 2 of those three. That's a lot of progress on the theory side that hasn't yet made a big dent on the practice side. Since I'm coming from the practice side, I'm still viewing it from the perspective that we need to toss out the 3VL, for example. I'm not observing an industry that has done that, so it would not make sense for me to indicate that the issue has been resolved. I think we can see from cdt that it is far from being resolved. Make sense?

> > I don't know if those are what you are calling "the baby"
>
> No pointers. No dependence on manual navigation.

You are right, I'm a fan of navigation.

> Thinking in terms of
> propositions not objects.

I prefer not to dump either of those. Thinking in terms of entities, propositions, objects, and functions (relations with a primary key, possibly composite) are all helpful ways to think.

> Essentially the information principle.

I only ditch the information principle with normalization defined as it has been historically and still is by the majority of practitioners.

> We
> must not lose the invaluable insights if we are progress to even better
> techniques.

Agreed. I have mentioned that I find it sad that we did this with the introduction of the RM and I would hope we would not abandon everything we know about set processing as we start to add navigation back in. I do not find the DB2 9 approach very elegant at first glance, but it is an attempt to try to be true to the RM in some sense while still branching out. I would rather see SQL (not the RM) replaced but I understand how much of an industry standard it has become.

> > 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.

>

You suggested above that you did not like navigation, but perhaps it is "navigation only" that you don't like, in which case we agree.

> > 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-relation that has an identified primary key can be modeled as a function (mapping from key values to tuples). I pass the function a personId and I can get a last name back, for example.

> > > 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.

>

And some, such as lists (and nested lists), had been discontinued, losing favor almost overnight, with no emperical data nor solid proof to back up dumping them.

> > 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.

>

I am quite sure that there is now no single way that it is currently viewed in the theory. The term has been messed with sufficiently so that I typically have to write it as the form-formerly-known-as-1NF, but was hoping that the shorthand (understood by 90% of practitioners as the old version of the term, I would guess) was sufficient. Sorry.

> or as the retro-1NF definition of the early 1970's that you
> often use

that the whole bloomin' industry uses in practice, right?!!

> (and yes I understand that this is still an SQL-ism in
> industry).

yup

> >
> > > 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?

>

This relates to the meaning of "theory." Offering lists, NF2, 2VL is not the same as putting forth a set of axioms and deriving a bunch of stuff, but the topics are relevant to db theory, right?

> 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.

I have a theory about db theory related to the "proof" that relational theory is the one true theory (from Date and such). I might introduce it as a topic if I'm feeling frisky again, but I've lost my spark for now, with enough places to chat where I can be appreciated ;-( so I've been keeping a low profile here. We all need a little love sometimes, ya know. ;-)

> > > 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.

You do rank high on my list of people on cdt whose opinions I value.

> 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).

Yes, it is difficult for me to even come up with a possible way to set up a test of what I would like to collect data on (software development techniques including data models for persisted data, for example) where more than 50% of the industry would accept any conclusions of the test as meaningful. cheers! --dawn Received on Mon Jan 22 2007 - 06:50:42 CET