Re: In an RDBMS, what does "Data" mean?
Date: Sat, 05 Jun 2004 16:49:23 GMT
Lets look at
"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:QxXjHkHok7vAFwzH_at_thewolery.demon.co.uk...
> 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