Re: A Normalization Question

From: VHarris001 <vharris001_at_aol.com>
Date: 02 Aug 2004 17:19:57 GMT
Message-ID: <20040802131957.19243.00002689_at_mb-m04.aol.com>


>From: "x" x-false_at_yahoo.com
>Date: 2004-07-09 10:02 AM Eastern Daylight Time
>Message-id: <40eea5a1$1_at_post.usenet.com>
>
>
>"VHarris001" <vharris001_at_aol.com> wrote in message
>news:20040709093849.29796.00001162_at_mb-m18.aol.com...
>> >
>> >> Why isn't each "pet" considered a unique thing rather than a quantity?
>> >
>> >Consider other kind of quantities instead.
>> >How about money, weights and lengths ?
>> >
>>
>> Shouldn't the database program offer the flexibility to handle all data
>> instances? That is, it can be tracked if one person has pets (Y/N), how
>many
>> (QTY), how many of each (TYPE/QTY), individual pets, with names, breeds,
>etc.
>>
>> But to offer this flexibility in a typically normalized database requires
>too
>> many tables. Isn't the better alternative to contain all the data in one
>table
>> and use multiple pointers?
>
>You avoided the question.
>How do you model money, weight and length values ?
>

I've been mulling this over a bit, and think that one way to handle quantities might be to consder them a property of some 'thing' rather than multiple occurances of the same 'thing.'

For instance, a checking account is a 'thing' that contains money, but this is a little deceptive, because in reality the transactions on the account are the 'things' that contain the money.

In the model where there is one table containing 'things' and one table containing 'relations,' the checking account would be the 'thing' that contains all the transactions. The initial deposit would be the first 'thing' with a quantity, and all further transactions would be the 'things' bearing the quantity that change the balance on the account.

Transaction #1
08/02/2004

Transaction #1
Deposit (debit)

Transaction #1
100.00

If this was in an accounting module, we would have the same transaction flow through to the source of the funds (which is also probably a 'thing' such as an accounts receivable transaction).

Each account could have a 'beginning balance' to be used when balancing the account, as a 'thing' to carry the balance forward when purging audited transactions.

I would think the same model would apply to, say, a persons height or weight, although I haven't thought out exactly what the 'thing' is that contains the height or weight.

Would this solve the quantity problem in the things/relationship table model?

V Harris Received on Mon Aug 02 2004 - 19:19:57 CEST

Original text of this message