Re: In an RDBMS, what does "Data" mean?
Date: Sat, 26 Jun 2004 12:15:01 +0200
Message-ID: <40dd4ca1$0$93324$e4fe514c_at_news.xs4all.nl>
Anthony W. Youngman wrote:
> mAsterdam writes
>
>>> What I can see happening with relational is over-normalisation - >>> like making the mistake of pointing your invoice billing address at >>> your customer's accounts department. If the company moves, you've >>> just corrupted all your historic invoices... >> >> Yes, this might happen. >> MV beginners are immune to such mistakes? >> Somehow this reminds me of Neo..
>
> No - MV beginners could make the same mistake ...
>
>> Why blame the math for adding the wrong figures? >> Why do you grab this (over-normalisation) to >> discredit relational thinking?
>
> My bad. It's just that, in relational, you have to split out the
> addresses into another table, so "why not use the existing address
> table?" - a trap that's very tempting to a relational novice.
Yes, I've seen that happen many times. It even takes some convincing effort that by simply removing the billing-adress from the invoice, the novice is actually removing information (as in data, relevant to some action/decision), not redundancy.
> MV wouldn't have an address table to tempt the MV novice into that trap.
Sorry to be vague, but I can't (maybe just yet) get it concise:
MV.FILE obviously comes with more 'togetherness' and 'containment'
of the associated data than SQL.TABLE.
Also, MV.FIELD may contain more than SQL.COLUMN.
It may be a good exercise to think of MV.FILE as closer
to SQL.SCHEMA than to SQL.TABLE (and MV.FIELD to SQL.TABLE).
The crucial difference may be in the adherence to the information
principle. (In some other post you talk about having order
without specifying it, I think it is similar).
<quote>
[Information principle] (RM) Date/Codd:
Chris Date in "EDGAR F. CODD 08/23/1923 – 04/18/2003 A TRIBUTE":
The entire information content of a relational database
is represented in one and only one way: namely, as
attribute values within tuples within relations.
</quote>
Adherence to it comes with costs and benefits. You seem to be convinced that the benefits of non-adherence to it easily outweigh the costs (i.e. the benefits of adherence).
> That's not to say there aren't traps for MV'ers - one I've had to deal
> with recently was storing a list of prices, with just one "currency"
> field - and then I'm tearing my hair out because some prices are local
> currency in the market while others are "hard currency" shops or
> black-market dollar/euro prices :-( Damn users programming the system
> !!! :-)
COBOL was designed to make it possible for
users to program the system.
The problem to meet that design goal is this:
Some people are handy with it, others aren't.
As soon as some new language/tool/discipline,
designed for use by non-specialists, becomes important
enough, it is defeated by it's own success.
A new specialism is born. :-)
Received on Sat Jun 26 2004 - 12:15:01 CEST