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

Anthony W. Youngman wrote:

>>> 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 :-)

Yep.

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

Of course not. That is, in principle. It depends on what exactly you need to copy/add/subtract - if it's only amounts of shipped/incoming goods it's ok. So we can easily query the stock and delivery status of order items for a customer.

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

Why blame the math for adding the wrong figures? Why do you grab this (over-normalisation) to discredit relational thinking? Received on Thu Jun 24 2004 - 00:52:19 CEST