Re: O'Reilly interview with Date

Marshall Spight wrote:

> The namespace unification issue matches quite well with the
> predicate logic model as well; when you do some logical
> operation on two propositions, you necessarily have to unify
> their predicate's namespaces.
>
> The idea of joining only on FK or some references constraint
> is attractive, but I'm not sure if it's general enough. Sometimes
> you want to join Tables A, B, and C, where B and C both reference
> the primary key of A. What would that do? Or what if a table
> references a primary key twice?
>

Ken's contention is that foreign key columns should not be ever defined explicitly. A foreign key definition that specifies child table, parent table, parent table key (default: primary), and optional column renaming should be enough for many needs. Going further, you can have overlapping keys by specifing a foreign key with the flag "no columns" or somesuch so that it allows creation of the key if it can find previously defined matching columns.

Joins can then be specified between two tables by specifying the distinguishing features of the foreign key, and you can even leave out this step if doing so will unambiguously pick the right one.

So this:

SELECT child.* from parent join child

would be valid if there existed only one foreign between them. If there existed a myriad of keys and we chose to name the keys, we might do this:

SELECT child.* from parent join child key KEYNAME

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