Re: In an RDBMS, what does "Data" mean?

From: Eric Kaun <>
Date: Fri, 04 Jun 2004 20:10:56 GMT
Message-ID: <kH4wc.5267$>

"Dawn M. Wolthuis" <> wrote in message news:c9q5ng$vhm$
> "Eric Kaun" <> wrote in message
> news:u60wc.5736$
> > "Anthony W. Youngman" <> wrote in message
> >
> > > In message <40bd0b99$0$561$>, mAsterdam
> > > <> writes
> > > >Anthony W. Youngman wrote:
> > > >
> > > >mAsterdam writes
> <snip>
> >> Which is simpler - to model a single real world entity as a single
> > > database "table" as MV does (we can model an invoice in a single
> > > or as five or six relational tables?
> >
> > Why do you have attributes? You're, like, totally dissecting the
> > nature of the invoice, dude. C'mon, let's harmonize with the cosmic
> gestalt
> > and just have one big file with attributes INVOICE1, INVOICE2, INVOICE3,
> > etc...
> hey man, now you're talkin' but now we want to ask questions of the data,
> we need to tag some parts, without harming any animals, and there you have
> it ;-)

Heh... oh, so you don't give a darn about plants? Speciesist.

Asking questions is precisely the point of relational, and has been pointed out, relational is more egalitarian with respect to what you can ask, in that it requires that only relations (and tuples, which are directly implied) "tag" the data. Tagging, though, implies a high ratio of text to markup - else you end up with the mess that is many XML docs, with a 5:1 ratio of tags to data. And XML tagging has a limited type system, and nothing about constraints.

So when you say "tag parts", you've already decided on the format - an implication that the data comes "naturally" in some form. In my experience, that "natural" form is as useful as natural language is for programming, even with the tags.

Maybe I'd be swayed by a more complete tagging system, but I think it's the cart pulling the horse...

> > In what way does storing the invoice in a single file mean the business
> > analysis is simpler? You still had to identify attributes, and then of
> > course make sure the ordering of elements in the MV attributes is the
> same,
> > and possibly dissect values into sub-values...


> One way it makes it easier is that it takes us down to a smaller number of
> portals, namespaces, vocabularies, means of making our way into the data.
> If you don't think in terms of equal relations, but of some being
> entry points into the data, you simply things greatly for the user.

Some users. What about the users with other entry points?

> I don't
> know about thinking about ordering of the elements -- we don't give it a
> second thought -- you start tossing those puppies in there and add to the
> end or leave a few open spaces if you like it that way. No one spends any
> brain cells considering the ordering of attributes in PICK/MV. --dawn

I don't mean the ordering of attributes - I mean the ordering of elements within an attribute. For example, you have an invoice, which probably has a LineItem attribute, and a Part# attribute, and a Quantity attribute. As separate attributes, those aren't connected by anything but convention; and it's those sort of assumptions that normalization is meant to codify.

  • erk
Received on Fri Jun 04 2004 - 22:10:56 CEST

Original text of this message