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

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

> He did say that, and I've been thinking about it, and am not sure it's
> accurate. The order of values in a list attribute in a Pick file seems
> primarily to correlate with other attributes that relate to the same
> "nested" entity - e.g. a line item. Those can easily be spit out in
> correlated lists by foreign key traversal. Other ordering would have to be
> imposed, and maybe that's where the discrepancy is. Relational requires
that
> if order is important, you make it an attribute. I've never found such to
be
> a problem - in most cases, orderings are pseudo-IDs.

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. Received on Fri Jun 11 2004 - 13:09:21 CEST