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

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Sun, 12 Oct 2003 08:05:43 -0700
Message-ID: <bmbqfu$krgo9$1@ID-152540.news.uni-berlin.de>

Lauri Pietarinen wrote:
> Costin Cozianu wrote:
>

>> Lauri Pietarinen wrote:
>>
>>>
>>> In my mind the rational for using surrogates in databases is that
>>> they insulate us from cascading changes in the case that we have to
>>> change the primary key.
>>>
>> But this is a physical level concern. The table holding the foreign 
>> key, may just physically hold a pointer to the record from where it 
>> will get the (foreign key/candidate key)value. Then an "ON UPDATE 
>> CASCADE" will be just as easy as if there was nothing to cascade. 

>
>
> 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.

>> Plus the scenario you described is not quite kosher. In general you 
>> don;t allow users to update the logical identifier of an entity. For 
>> example he mistype his license number, so you want to update that 
>> information in all different tables. 

>
>
> That's true, of course, in some situations. Or it might be that after
> the policy has reached a certain state the license number can't
> be modified. All the same I have seen such situations appear in practice,
>
>

>>
>> 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.

In any case, in the example above it was about a "data type" i.e. a the type of a value to be put in a column.

> Lauri
>

Costin Received on Sun Oct 12 2003 - 10:05:43 CDT