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

From: Roy Hann <specially_at_processed.almost.meat>
Date: Thu, 15 Oct 2009 08:39:26 -0500
Message-ID: <>

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?

Having a single table amounts to having a constraint that says that the two facts (the fact about a specific donor and the fact about a specific donation) are incapable of being learnt separately by the business.

Can one have a donor who has not donated (yet)? Can one have a donation without it comes from a donor? Can one have multiple donations by one donor? If the answer to ANY of these questions is yes, then one appears to need two tables. If the answer to ALL these questions is no, then one appears to need a single table in order to enforce an always correct representation of the business knowledge.

Of course my argument appears to break down if one is willing to permit nullable columns, but I'm not.

Received on Thu Oct 15 2009 - 15:39:26 CEST

Original text of this message