Re: 3vl 2vl and NULL

dawn wrote:
> Marshall Spight wrote:
> > I'm in an editor kind of mood, having been doing book reviews lately.
> > I'm appointing myself editor of the post I'm replying to.
>
> Having read it, I see you would like me to treat my conversation here
> more like a published work. It takes much longer to write something
> short and suscinct, and I do try, but will give that more effort.

Strunk and White advises "omit needless words."

> > So to communicate
> > this concept, you shouldn't say you're against normalization.
>
> I am using the meaning of the term when the term was coined for use
> with data. I can point to the appropriate references each time I use
> the term so that there is not misunderstanding. We have the same
> problem with 1NF as Date now has that include relation-valued
> attributes.

I really don't think it's a good idea to base your terminological choices
on what was current in 1970. By that metric, when you say "a modern statically typed language" I should understand you to mean Fortran or Cobol. Instead, I think you should use terminology in a way that is current. It is of course your choice.

> > Okay, non-1NF is one thing. "Ordered lists" is redundant; just say
> > "lists".
>
> Yes, I could say "lists" but you are not right that it is redundant.
> Lists are ordered within the computer. Ordered lists are lists where
> the ordering has meaning.

Some people use a list where they should be using a set. The fact that some people do this doesn't change the fact that a list is ordered. So I maintain that "ordered list" is redundant. Also, it is an especially bad choice because there is already a term "ordered set", distinct from "set" and distinct from "list". Also, "list" is a standard term.

Those people who use lists when they should be using sets are overspecifying. We shouldn't let common mistakes influence our terminology overmuch.

> >From a practical standpoint, I am OK with combining these so that there
> are no relation-valued attributes, but lists (ordered or not) as
> attribute values. It might be better to have the option of rva or
> list, but both XML and MV retain an ordering in nested elements and
> that works for me. Neither of them provides features for making clear
> whether the user cares about the ordering. That means we are not
> capturing the full semantics in the model.

Agreed.

> > 2VL is a third thing. This is a good
> > list; it is specific. But above you said "I'm trying to convince
> > 'the industry' to adopt more flexible (dare I say 'agile') data models"
> > but then you followed it up with an entirely unrelated list of desired
> > features. Nothing about nested relations, lists, and 2VL says "agile".
>
> They are not unrelated.

Maybe, maybe not. But you haven't established any connection between them.

> It is my starter list, my top 2 (or 3 by your
> count). Since I'm starting from looking at what works today as an
> agile approach and trying to work backwards into what features might be
> accounting for this, I'm sure I will add to my list in the future. My
> example of e-mail addresses gives a hint at what types of flexibility
> having lists adds to the mix.

Okay, I see you're doing it top-down whereas I'm advocating bottom up; that's simply a different but valid approach. But I would request that you not just stay at the top, and ground your arguments with specific features. At least at some point.

> Maybe the industry should have done that instead of asking Bill G for
> "security."

I'm sorry, but where did that come from? Weren't we talking about databases a minute ago? Did I mention that I'm concerned about America's dependence on foreign oil?

> The fact that no such emperical data were collected at the start of
> moving a large portion of the industry over to the relational model
> might have been a mistake.

Or it might not. We can go round and round on this one and not get anywhere. Let's not do that.

> This seems like a newsgroup where someone
> might have a eureka moment on how to test a theory in this way. Should
> all of our tests assume our theory (e.g. mathematical proofs within a
> particular model)?

My point is that these tests are prohibitively difficult. You can disprove
this by coming up with a test that is not difficult or expensive. It would be great if you did! But I won't be holding my breath.

Until you do manage to come up with such a test, there is not much to discuss.

> That said, OK, Marshall, I hear you that much of this audience might
> have no interest in testing the usefulness of theories in this way.

I guess that's one of your subtle digs. Ha ha! Nice one.

The relational algebra is supremely useful. Perhaps we could make it more useful by extending it to include support for lists. Or union types. That's the conversation I'd like to be having. How to make our systems and tools more useful. What specific features would we like.

I sense you would also be interested in this conversation, yes? Could we have that conversation please?

Marshall Received on Fri Feb 17 2006 - 21:38:59 CET