Re: O'Reilly interview with Date

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Fri, 12 Aug 2005 09:13:20 -0400
Message-Id: <9qjus2-hci.ln1_at_pluto.downsfam.net>


Marshall Spight wrote:

> Kenneth Downs wrote:

>>
>> Theoretically I think it is better that two columns of the same name must
>> always have the same domain.  It seems that those who would allow the
>> opposite have the burden of proving the benefit.

>
> I tend to agree, but there are issues. On the one hand, different
> tables
> are different namespaces; on the other hand they aren't. I say they're
> the same because you might have to unify their column names when
> joining
> (whether we standardize on natural join or not.)

Thorny issue. Technically yes a single table is its own namespace, but as soon as you join to another table you have to contend with those names.

> They are different
> because the constraint you propose is probably too onerous. If we
> have a database with thousands of attributes (which is quite possible)
> then we would probably be unhappy having attribute names required to be
> globally unique.

I think the scale problem expresses in two ways.

First the problems extends upward through hierarchy. Namespaces for table, schema, database, world. Then it extends within any of those contexts through sheer size. Big table, big schema, big database, big world.

We can look to extremes and say that a single shop can maintain and benefit from 1 name=1 domain through technology and policy. We can also say that the world cannot do it and cannot benefit from it because there is more than one authority and more than one technology in use world-wide.

But the interesting middle ground is people who have agreed that 1 name = 1 domain but who are working independently, and who may then need to have their systems work together only to discover they have chosen the same column names for different domains. This BTW came up at my first demo of Andromeda.

It seems reasonable in this case to allow each shop to put their domain definitions under a "namespace" definition. When data travels between two systems in the same namespace, it can assume 1 name=1 domain, but when it travels across namespaces, it would have to perform translations.

The final difficulty with that is if I want to take your nifty table definitions and add them directly into my system as a module, but we have conflicting column/domain definitions. I haven't worked that one out yet.

>
>

>> Alas, this would break
>> all of that sofware out there written by people who pay good money for db
>> servers to Oracle, MS, IBM, and friends, so it is just not commercially
>> viable at this time to introduce this restriction.

>
> Since this is a theory newsgroup, I have the benefit of being able
> to wave my hands at that problem and pretend it isn't there. :-)

hee hee

<snip>

>

>> But anyway, moving forward, a query is just a list of desired columns (we
>> apply to user's filters like defect=123 at runtime) from tables, so the
>> query would be:
>>
>> query Myquery {
>>   table bugs {
>>     column { bugid; }
>>   }
>>   foreign_key users {
>>     suffix: _rep;
>>     column { login; }
>>   }
>>   foreign_key users {
>>     suffix: _own;
>>     column { login; }
>>   }
>> }

>
> Okay. What are the three column names of the result set?
> is it (bugid, login_rep, login_own) ?

Yes.

> If so, I would say
> that you do, in fact, address the namespace unification
> issue.

At least within the scale of a single database.

>
>
> Marshall

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Fri Aug 12 2005 - 15:13:20 CEST

Original text of this message