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

From: Eric Kaun <ekaun_at_yahoo.com>
Date: Fri, 11 Jun 2004 20:39:38 GMT
Message-ID: <eMoyc.25262$674.5547_at_newssvr31.news.prodigy.com>


"Laconic2" <laconic2_at_comcast.net> wrote in message news:T_GdnUOFSYwWD1TdRVn-vA_at_comcast.com...
>
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:N23yc.2596$gz6.16_at_newssvr15.news.prodigy.com...
>
> > I understand what you're saying - but as the number of departments (or
> even
> > job roles within a department) demands different views of the data, I
> > believe that whatever vocabularies you layer on top, your "base" data
> design
> > tends toward normalized relations.
>
> I believe what you say. I also believe that this is what databases are
for:
> sharing data between organizations that don't have a common view of the
data
> being shared.
>
> Half of the databases being built today should have been built using file
> systems. It would have been faster and cheaper.
> And there's no significant sharing being done. It's all encapsulated in a
> single subsystem.

I agree with you from one viewpoint; on the other hand, an RDBMS doing its job (we have a bit of an employment gap in that regard) would also help your design (not just data design); I'm thinking of the ability of a TRDBMS to encode business rules. If that engine also had a significant client-side presence (which it should!), you'd be doing design in a more general sense than just "data design".

> Months ago, I asked whether a pizza with pepperoni and onion was the same
> as a pizza with onion and pepperoni.
>
> I got several cute responses, but nobody really addressed the underlying
> issue. Sounds like you've got a handle on it.

It's a slippery handle, but maybe - but be careful asking about "the same as" in an OO context - that subject gets very confusing to OOers. :-)

A related and interesting issue is that of relation-valued attributes as primary keys; for example, from one of Date's non-free papers, a relation with a single column: a relation of siblings. Since in a relation order is irrelevant, you couldn't insert the tuple ( {Eric, Curt, Amy} ) if the relation already contained ( {Amy, Curt, Eric} ), for example. He did a similar thing with prime factors; the relation consisted of 2 columns: Integer and {Integer}.

Anyway, I'm rambling...

  • erk
Received on Fri Jun 11 2004 - 22:39:38 CEST

Original text of this message