Re: relational reasoning -- why two tables and not one?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 14 Oct 2009 23:07:11 -0300
Message-ID: <4ad683d3$0$23763$9a566e8b_at_news.aliant.net>


paul c wrote:

> lawpoop wrote:
> 

>> On another mailing list about a database which shall not be named, a
>> poster asked about a single-table database structure. It was to track
>> donations, and that thank-you letters had been sent in reply.
>>
>> A couple folks ( myself included ) thought that there should be at
>> least two tables -- 'donors' and 'donations' . But the poster argued
>> that no, there would never be a holiday fund drive appeal sent out to
>> all donors, or a year-end statement, or anything of that sort. So a
>> single table would suffice.
>>
>> I tried to argue the point that having 'donors' and 'donations' more
>> accurately modeled 'reality' , and failed. Another poster, who was in
>> fact in favor of two tables, argued against the 'modeling reality'
>> argument, saying that theorists would it's wrong to have
>> 'donation_dates' as a separate table, even though the relationship "in
>> reality" is one date for many donations. If it meets the functionality
>> specs, it's fine.
>>
>> ( There was talk of needing Donors as an entity later on, but there
>> was no need for it in the specs now, so it's moot ).
>>
>> I couldn't think of a good argument against it, so I must be wrong.
>> But my gut instinct or intuition is telling me there is some
>> understanding of relational theory or something that I am not
>> grasping, which would prove insightful in this discussion.
>>
>> Thoughts and comments?
> 
> Whose reality?  Also, theory doesn't dictate requirements.  As Ralston 
> Saul suggests, there has been no such thing as absolute reality since a 
> few hundred years ago.  When Date writes about modelling reality, I 
> think he means it very loosely.  Reality as a target risks inventing 
> imaginary requirements although I realize there is a going industry 
> based on foisting that on users.  Apparently the poster eliminated a 
> number of possible requirements so a single table doesn't seem 
> unreasonable given the 'meagre' information as Bob B put it, even if 
> some donors are repeat donors.

Even then, it is historical data. For the same donor, all the information might be the same from one donation to the next, or it might all be different. Assuming one wants to record the information as it was   (or as it was reported by the donor) at the time of the donation, few if any functional dependencies are likely to exist.

Unless, of course, one creates a temporal database, but even then, the charity seems to collect no information about intervening points of time so a temporal database seems inappropriate too. Received on Thu Oct 15 2009 - 04:07:11 CEST

Original text of this message