Re: 3vl 2vl and NULL

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.

dawn wrote:
> Marshall Spight wrote:
> >
> > Wait-- are you saying you *advocate* denormalization? Can you clarify
> > this please?
>
> Yes. I advocate data not being in 1NF (as indicated in the Is Codd
> Dead? blog entry I've mentioned before). When you move from PICK to a
> SQL-DBMS, you have to split out the data into 1NF.

Okay, bad phrasing on your part then. "Normalization" is the entirety of a bunch of things, 1NF being the weakest of them. So to communicate this concept, you shouldn't say you're against normalization. You should say instead that you favor nested structure. Note that this is not incompatible with relational algebra, although it does introduce challenges.

> > > I'm trying to convince
> > > "the industry" to adopt more flexible (dare I say "agile") data models
> > > and related tools.
> >
> > Can you be specific about the features of the model you want,
>
> non-1NF (including ordered lists) and 2VL might be a good place to
> start

Okay, non-1NF is one thing. "Ordered lists" is redundant; just say "lists". Lists is a second thing. 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". Probably you should drop the "agile" and focus instead on the specific additional capabilities you want. This would be more concrete. It would give your reader a clearer idea of what you are thinking.

We get an entirely different idea about a person who says "I want a lot of money" than we get from a person who says "I want to go out and work hard, and I hope thereby to get a lot of money." That first guy is a lazy dreamer; that second guy is going to really make something out of himself one day.

The specific features you want come first; the expected/desired benefits come second, and can even be omitted from the conversation, if you can justify the need for the features.

> > the kind of operations supported on the model,
>
> I've mention the ripple delete (remove a value from the midst of a list
> and rest of the list moves up). Many others too, of course.

In my mind "ripple delete" is a given assuming lists, so this would be filed under "list support" in your argument. Probably there should be a whole discussion about list operators.

> The key issue is flexibility, making the development and maintenance of
> software less costly. Individual vendors of tools, such as IBM,
> Intersystems, Revelation, jBASE have details on how to use their
> products. There are a number of well-documented issues with SQL,
> including both theory and practical issues.

As an editor, I would strike out all the above. It doesn't say anything sufficiently specific to communicate anything to your audience. Brevity is the soul of wit.

> The two I'm starting with are 1NF and 3VL.

That's a good sentence! That communicates a specific idea, and it has the benefit of being short.

> > Note that I am not asking for "proof" of anything. Proof of
> > cost/benefit is not possible
>
> agreed.
>
> > and I suggest you abandon that search.
>
> It isn't proof, but don't you think some emperical data would be
> helpful?

Sure it would. I expect for only ten million dollars or so, you could set up a halfway decent comparison. If you are actively soliciting a business school to do this, it is worth discussing in this post. Otherwise not. Again, I suggest this line of argument be dropped as non-productive.

> > Instead I am simply asking for examples. Sort
> > of like, here's a problem I had once, and it was solved
> > with MV like this, and see how much harder the SQL
> > version of this solution is? Even the last is optional.
>
> It is complex enough that any example would be some tiny look.

Okay, this is a weak response. You need to punch it up or you're going to lose your audience. It sounds like you know the question will make you look bad, so you're avoiding answering. The guy didn't ask for a lengthy response; what he asked for was quite reasonable.

> That is
> why I thought perhaps I should get an MV and SQL solution to the same
> problem in order to illustrate. But to answer your question, here is
> an example of a pattern that is repeated often that obviously could be
> solved by SQL systems (all examples I care about can be).

Here again is a set of sentences that can be safely excised.

> A system includes a single e-mail address and there is a new
> requirement to collect all such e-mail addresses, with the best one to
> use first and so on for as many as we have for an individual. The
> change is made to describe the e-mail value as a list. This can be
> done with changes to anything but this description to start with,
> requiring no changes to regular reports or queries (they will simply
> list the values one under another), although output forms need to be
> changed if there are such. Even the input systems and other processes
> continue to work and can be changed as needed to take in a list instead
> of a single value.

Okay, relative to SQL there are bunch of things different here. You've done a good job of describing a *specific* example, which is excellent. Now you need to analyze that example and pick out specific features of the development platform that you like. I note that it appears the UI derives directly from the data model, and that cardinality can be changed in the running system. Both interesting features. Are they equally important? Are there others? We are back to discussing *specific* features of the platform, and that's where the conversation should be focused. Keep it up; let's see more like this.

> > My big frustration with your quest is that for all the
> > messages you post, I still really don't know anything
> > *specific* you think would be beter with MV than with SQL.
>
> What format would such specific information take? I'm OK with XML (it
> permits non-1NF and 2VL), JSON, and OO, as well as MV, and I'm not
> trying to design some altogether new data model. The problem I have is
> with the RM, including the 1NF and 3VL aspects of it among other
> things. I'm trying to make it clearer in my blog in case that helps.

Again, a weak response. The questioner is asking about specific features, and you're asking about format. If someone doesn't like your format, they can specify that later, but here it's like you're anticipating
communication problems that haven't even had an opportunity to exist yet.

For final publication, I'd rewrite this post, and shoot for laserlike focus on:

1) nested structure
2) list types + operations
3) The email example. Decompose this into specific features.

You can mention 2VL as well, but you don't have to go into it because it's well trodden ground.

Marshall Received on Fri Feb 17 2006 - 06:32:00 CET