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_at_pluto.downsfam.net>
>> 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.
Date: Sun, 14 Aug 2005 10:23:34 -0400
Message-Id: <2m04t2-eoe.ln1_at_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_at_(Sec)ure(Dat)a(.com)Received on Sun Aug 14 2005 - 16:23:34 CEST