Re: In an RDBMS, what does "Data" mean?
Date: Mon, 21 Jun 2004 20:03:13 +0100
Message-ID: <Dor3B3AxDz1AFwB+_at_thewolery.demon.co.uk>
In message <40d5557f$0$43451$e4fe514c_at_news.xs4all.nl>, mAsterdam
<mAsterdam_at_vrijdag.org> writes
>> As for the logistics manager, yes why should she be interested in
>>invoices (apart from checking that what was billed actually arrived,
>>or what was sent actually got billed). I would guess that in her STOCK
>>she will have attributes like SHELF, QUANTITY and so on. What's in
>>stock is different data to what's been billed :-) so it lives in a
>>different FILE :-)
>
>That was what I hinted at / suspected. How would a MV implementation
>deal with the sameness of those FILEs, the SHARING of the data between
>ORDERING, STOCKING, DELIVERING and BILLING the GOODS? (auch! this hurts
>my eyes :-)
Pretty much the same as relational I would guess. You have a file to say
what your ORDERS are. You can link that to DELIVERIES ie what arrived -
and that feeds into STOCK. Then you have SHIPPING and BILLING.
I'd copy the item data from one file to the next in MV, but I'd do
exactly the same in relational. There's no guarantee that what you
ordered is what's delivered. You might store stock as a running total or
you might track movement in and out and get your stock levels by
summing. And then you've got no guarantee that what you ship and what
you bill are the same thing.
I don't see duplicating data like that as breaking normalisation. 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...
Cheers,
Wol
-- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999Received on Mon Jun 21 2004 - 21:03:13 CEST