Re: O'Reilly interview with Date

Kenneth Downs wrote:
> Marshall Spight wrote:
>
> >>
> >> SELECT child.* from parent join child key KEYNAME
> >
> > Okay, but this doesn't address the namespace unification issues
> > that I raised previously.
>
> Why not?

Because you haven't specified a name for the columns in common.

We may be talking past each other here; I'm speaking about the theoretical issue, and perhaps you're speaking about layering a system on top of SQL.

Recall that I was originally responding to David Cressey's critique of natural join. I said "you necessarily have to unify the column namespaces when you join, unless you don't want to enforce any column naming discipline at all (that is, allow columns with no names, or illegal names, or two columns with the same name) which I don't think is tenable."

Note that SQL falls squarely into the "[doesn't] enforce any columning naming discipline at all" case. See any of a dozen essays by Date et. al. on why this is bad. :-)

Let me give a concrete example, and you can tell me how you would handle it in Andromeda.

I have a table for software defect reports, called Bugs, and a table of Users.

create table Bugs(
  BugId int primary key,
  Reporter int references Users(UserId),   Owner int references Users(UserId),
  Title varchar(255)
);

create table Users(
  UserId int primary key,
  Login varchar(32)
);

If I'm preparing a report for defect 123, I probably want to show the Login of the owner and reporter, instead of the numeric id. So I might do this

Select
  BugId, Title,
  ownerUser.Login as OwnerLogin,
  reporterUser.Login as ReporterLogin
from
  Bugs, Users ownerUser, Users reporterUser where
  BugId = 123 AND
  Owner = ownerUsers.UserId AND
  Reporter = reporterUsers.UserId;

I use a column naming discipline here, to good effect. SQL doesn't require me to, but I do it anyway.

Marshall Received on Thu Aug 11 2005 - 04:39:17 CEST