Re: Distributed foreign keys (was Re: Category Types)

From: daveb <davebestOBVIOUS_at_usa.net>
Date: Tue, 24 Jun 2003 22:53:54 -0700
Message-ID: <80GdnRI0pJ1vpWSjXTWc-w@speakeasy.net>

"Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:bdapdg$r9780$1_at_ID-152540.news.dfncis.de...
> Paul Vernon wrote:
> > "Alexey Kirich" <kirich_a_at_softline.kiev.ua> wrote in message
> > news:3ef01f21$1_at_ns...
> > [snip]
> >
> >>This approach can be made with hope, that in the future RDBMSs will
support
> >>OR like foreign constraints.
> >
> >
> > Hugh Darwen has a proposal for such "distributed foreign key" shorthands
in
> > this presentation.
> >
> >

http://www.hughdarwen.freeola.com/TheThirdManifesto.web/Missing-info-without -nulls.pdf
> >
> > Regards
> > Paul Vernon
> > Business Intelligence, IBM Global Services
> >
> >

>

> I've read it, and my personal opinion is that it's totally flawed.

>

> Here's the "recomposition" query:

>

> WITH (EXTEND JOB_UNK ADD ‘Job unknown’ AS Job_info) AS T1,
> (EXTEND UNEMPLOYED ADD ‘Unemployed’ AS Job_info) AS T2,
> (DOES_JOB RENAME (Job AS Job_info)) AS T3,
> (EXTEND SALARY_UNK ADD ‘Salary unknown’ AS Sal_info) AS T4,
> (EXTEND UNSALARIED ADD ‘Unsalaried’ AS Sal_info) AS T5,
> (EXTEND EARNS ADD CHAR(Salary) AS Sal_info) AS T6,
> (T6 { ALL BUT Salary }) AS T7,
> (UNION ( T1, T2, T3 )) AS T8,
> (UNION ( T4, T5, T7 )) AS T9,
> (JOIN ( CALLED, T8, T9 )) AS PERS_INFO :
> PERS_INFO

>

> This is simply put an abomination. As Dijkstra has noted in mathematical
> elegance is our most effective tools to manage complexity.
>
> The query above is not mathematical elegance, it is mathematical
clumsiness.

>

> What was there to discuss about it ?

>

> Cheers,
> Costin

>
Seems ok to me as long as an elegant shorthand for it can be defined. In fact, providing all the primitives and a sufficiently expressive grammar so that arbitrary shorthand's can be defined strikes me as being both elegant and practical. In which case, this criticism would be like dissing SQL because the results of the optimizer can generate inelegant and cryptic path expressions.

Unfortunately, I'm not knowledgeable enough to know if such a grammar is feasible, so flame away if I'm talking rot. But ISTM that this could make for a highly interesting topic. I'm late to the party, so perhaps it's already been discussed to death?

--
David Best
(Remove the obvious to reply)

Received on Wed Jun 25 2003 - 00:53:54 CDT