Re: Abstract identifiers, logical pointers, or foreign keys considered not enough

>>> Do you mean some kind of table reference, like has been discussed in
>>> this thread?
>>>
>>> RELATION Dept ( Id Dept_Id KEY, Name String );
>>> RELATION Emp ( Id Emp_Id KEY, Dept REF(Dept),
>>> Name PersonName, Salary Money );
>>>
>>> RETRIEVE E.Name, DEREF(E.Dept).Name FROM Emp E;
>>>
>>> RETRIEVE E.Name FROM Emp E, Dept D WHERE DEREF(E.Dept).Id = E.Id
>>> AND D.Name = 'shoe';
>>>
>>>
>>> If so, I think this approach will complicate things unnecessarily.
>>>
>>
>>
>> Not at all, if this mechanism is part of the physical implementation
>> level.
>
>
> What do you mean by "physical implementation level"? That it is not
> visible to the
> user (meaning here the one that issued the query)?
>
>

Yes, how it is implemented, ti is not visible to the users. In abstract we talk about relation over Employee * Departments, the users should not care that in Oracle the best is to create a surrogate for department, or in other base they have to work with REF/DEREF. If the relation is implicit, one can just right

Select * from USERS NATURAL JOIN DEPARTMENTS

Or, you could as easily say

select users.*, users.dept from users

Where users.dept denotes the whole dept record.

Why do we need to let the user care that we implemented the relation with a VARCHAR DEPT_ID or a AUTOINCREMENT DEPT_ID or whatever other implementation technique that has nothing to do with Employee * Dept.

>>> Regardless of the problem related to changing the identity of
>>> entities, in the case I presented, introducing a PAYMENT_ID is a
>>> strange way to plumb the inadequacy of a type system.
>>>
>>> By type system, do you mean datatypes (=Domains) or table types?
>>>
>>
>> Table types are data types, in other words it is not profitable at all
>> to have first class types and second class types.
>
>
> Am I to understand that you do not make a distinction between table
> types and scalar, or data types?

No. They are all types.

> What do you understand table types to be?

Types derived from other types through a type constructors.

Would, say the table (or
> relation)
> PERSON(ID INTEGER, NAME STRING) be of type (INTEGER, STRING)?
>

It depends on named vs. unnamed perspective. If we choose names to be significant, and for all practical purposes they should be, we can define the table type to be (informally)

SET (RECORD { id:integer, name: string } )

in a ML-like language it would be:

{id: int; name: string} set

> best regards,
> Lauri Pietarinen
>

Best,
Costin Received on Sun Oct 12 2003 - 22:55:16 CEST