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