Re: Resiliency To New Data Requirements

dawn wrote:
> [...]how else was a girl sittin' in the
> middle of the corn fields not connected to any large corporations gonna
> get thousands of readers for the launch of her blog?

Dawn, be fair here. I've seen web sites that specialize in corn-fed midwestern girls working creatively to get thousands of subscribers.

:-)

> I'm definitely
> not diss'ing the relational model like the RM-advocates have trashed
> the models that came before it (even though they seemed to have ZERO
> emperical data to prove their point).

Probably true, but computing history, and probably math and logic too, is filled with models and ideas for which no empirical evidence of superiority exists. Physical sciences have it, of course, primarily in the coinage of prediction.

> I'm an end-user of DBMS tools [...] They need to permit
> developers to specify data structures such as lists

I don't necessarily agree here. There are many programming languages which would cheerfully ignore many programmers' requirements that they need to use pointers, or need to have a GOTO, or what have you.

> and, generally, to
> model data in a way that is more flexible for software development and
> maintenance over time. Lists [...] are useful.

But that's the main point of disagreement. If I believed that lists were that useful, I'd be on your side (although that's somewhat beside the point). Most uses of lists that I see are simply inferior to sets or relations. I find them hopelessly specialized for most purposes, and introducing them into a relational data model involves tacking on a specialized syntax and semantics for a data structure already subsumed by relations (and with little work).

> In theory lists can now be defined with user-defined domains in the RM,
> but they are not integral to the RM "data model" and I want them in any
> "data model" I use for typical DB101 applications. Why not?

"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupery

> Whatever the hang-up is, get over it.

No. I don't wanna.

> It was proven useful before Codd to
> employ them and it is still useful to model "property lists" as
> multivalued attributes. Many developers do it all the time in software
> applications today.

In my experience, I've found far more cases than not where correcting a bug or extending the system required re-designing such multivalued attributes: introducing either something more general and unordered and easily-accessed (e.g. a map), or something with a hard-typed interface (e.g. different slots for different values and attributes, additional classes for "special values", etc.). In cases I've seen, such lists (and in fact most lists) occupy the "sour spot" between generality and specificity, with most of the disadvantages of both extremes and few of the advantages of either.

> For a couple of decades many felt guilty about not
> "normalizing" their data, but that isn't what I hear today. NF2
> (Non-first-normal-form) and 2VL (two-valued logic) data modeling is on
> an upward trend. It is time to ditch The Information Principle."

Why? Relations don't conflict with however you want to define your domains. Even Pick is simply vaguely relation-flavored with system-defined, syntactically significant 1 and 2 level lists as an available attribute type. Even in MVDBs, you're not ditching the Information Principle entirely, as the top-level container is still the relation.

> However ignorant (sure) or arrogant (you don't know me then) you think
> I am, I don't waste my time writing about how others are less
> intelligent, more arrogant, or more ignorant than I [...]

True enough; I think Keith dragged you back into this NG in a fashion needlessly rude.

• erk

> P.S. I figured I respond so that you didn't look like a coward
> attacking someone who wasn't around to defend herself. smiles.

Ouch. Nicely done. Received on Fri Aug 11 2006 - 21:09:33 CEST