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

Lets look at
"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:QxXjHkHok7vAFwzH_at_thewolery.demon.co.uk...

[snipped]

> And just because relational may be simpler than codasyl doesn't mean
> that it's a good thing. We have a real-world problem here ... look at
> the following mapping ...
>
> real world <=> business analysis <=> database

Here's an visual example:

:LIST APHIST '340*VR11-1' INVDATE DESC ACCTS AMTS

APHIST.... INV-DATE Description......................... Acct..
Acct/Amts....
340*VR11-1 11-01-00 LOAN PAYMENT, NOV        5170        999.22-

3370      1,977.23-

5170          0.00

3370          0.00

This is a single A/P invoice with multiple G/L account#s defined (and amounts). This invoice will update four G/L accounts in the general ledger and financial statements by the amount "associated" with each account#. These are the properties (some anyway) of this invoice. The invoice is _not_ like:

:LIST APHIST '340*VR11-1' BY-EXP ACCTS INVDATE DESC ACCTS AMTS

APHIST.... INV-DATE Description................................ Acct...
Acct/Amts....
340*VR11-1 11-01-00 LOAN PAYMENT, NOV               3370      1,977.23-
340*VR11-1 11-01-00 LOAN PAYMENT, NOV               3370          0.00
340*VR11-1 11-01-00 LOAN PAYMENT, NOV               5170        999.22-
340*VR11-1 11-01-00 LOAN PAYMENT, NOV               5170          0.00

To alter the invoice, when preparing it for data storage, is to alter its fundamental structure. Although, in many instances it can be put back together again, sometimes it cannot. In addition, there's a lot of work to go through in order to decompose then recompose this invoice. This additional complexity, I think, is unnecessary and costly.

Then again, cost and complexity may not be an issue for some.

Bill Received on Sat Jun 05 2004 - 18:49:23 CEST