Re: O'Reilly interview with Date

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sun, 14 Aug 2005 10:23:34 -0400
Message-Id: <2m04t2-eoe.ln1@pluto.downsfam.net>

Paul wrote:

> Kenneth Downs wrote:

>> To disprove the idea, you'd have to have an example of a JOIN that
>> produced true results between two tables where both tables contained the
>> same column
>> but where the tables were not joined by a foreign key. One example might
>> be a job-based workflow system, where all invoices and production orders
>> are tied together through a job control system. Both Sales Orders and
>> Purchase Orders are children of the JOBS table, so each of them contains
>> the JOB_NO column, but they are not related to each other by a key. So
>> you
>> can join them, but to what purpose? You get a meaningless jumble of
>> Sales
>> order and purchase order properties. A more proper relationship between
>> these two tables would be a UNION, which might give the meaningful result
>> of showing activity over time. In fact there is probably another thesis
>> in here that two children of a single parent relate as UNIONs.

> 
> For this semantics it might not make sense, but it other cases it could
> be a valid thing to do.
> 
> For example, suppose you have a table of products.
> 
> Then another "child" table that gives the available colours for each
> product (assume the range or colours is different for each product).
> 
> And another similar table for the available sizes.

This is actually done the other way around. There is a table of available sizes, another for colors, another for label, and a fourth for dimension (not the same as size).

The table usually called STYLES is the list of valid cross-referenced values. The simple cartesian product of the constituent tables does not yield valid results.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

Received on Sun Aug 14 2005 - 09:23:34 CDT