Re: Abstract identifiers, logical pointers, or foreign keys considered not enough
Date: Sun, 12 Oct 2003 11:11:13 +0300
Message-ID: <3F890CA1.20405_at_atbusiness.com>
> 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),
RETRIEVE E.Name, DEREF(E.Dept).Name FROM Emp E;
RETRIEVE E.Name FROM Emp E, Dept D
If so, I think this approach will complicate things unnecessarily.
Name PersonName, Salary Money );
WHERE DEREF(E.Dept).Id = E.Id AND D.Name = 'shoe';
> 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.
>
> 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?
Lauri Received on Sun Oct 12 2003 - 10:11:13 CEST