Re: Resiliency To New Data Requirements

erk wrote:
> 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'll check with them and see if they can give me some tips.

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

Yup, like that "earth is flat" and "sun goes around the earth"

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

Doesn't stop users from indicating what they think they need, however. So, maybe I'm just an old goat asking for my pointers back. Maybe, but I don't think so. I recall working with someone like that -- a person who didn't want to move forward. I do want to move forward, and I want forward to include some of what has been highly effective in the past.

I just heard an interesting statement on cdp and don't know if it is true, but I'll repeat it anyway. Someone suggested that IBM has a large catalog of off-the-shelf solutions using their DBMS tools and there are more U2 apps than DB2. Can that be true? Those DBMS's order attributes, uniquely identify attributes by their position in a tuple, use descriptive not prescriptive schema with everything being a string (or binary, but ignoring those) that could be described as an integer and also a character string, for example, assumes all attributes can have values of variable length, and generally would be seen as out of line with relational theory. Maybe all they have going for them is the flexibility and related low cost of development and maintenance of software applications.

Yes, I'm very interested in emperical data, even if also liking-ish theory

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

Have you ever seen people model lists by assigning numbers with gaps so that other items could fit "in between"? GL account structures are famous for that, but it is a rather pathetic "design pattern", don't you think? What about adding an ordinal as an attribute to create a list without leaving gaps? Developers then reimplement the functions for inserting and ripple deletes.

Worse than that, there are lists that would be good for the user, but that 1NF designers leave as single-valued just because it is too much work to jump from 1 to n. When something is a pain in the neck to do, developers can more easily justify not doing it.

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

Good party line there, erk

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

So I suppose my house would be better without the whirlpool tub?

> > Whatever the hang-up is, get over it.
>
> No. I don't wanna.

If you really need to keep your pointers, that's your issue ;-)

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

We clearly have had different experiences.

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

OK, then, at least the Information Principle as it was understood by everyone before 1990 and by the masses even today.

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

I'm not at all opposed to modeling with relations, it is just that the IP requires exclusivity and I want the model to also "understand' lists, for example.

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

thanks. smiles. --dawn Received on Sat Aug 12 2006 - 05:13:52 CEST