paul c schrieb:
> Jan Hidders wrote:
>
>>
>> Another small thing is updating primary keys. If a primary key has
>> accidentally been entered wrong and you want to fix that with an
>> update then it is usually not possible to simply update it, and the
>> problem gets even worse if it is also refered to by foreign keys. In
>> an ER model this is a non-problem.
>>
>
> like a few other people (i suspect we are a minority), i think of
> 'update' as a sugaring or shortcut. ignoring transaction or concurrency
> issues, is there any logical difference between 'update' and the
> combination of 'delete-insert'? (granted the latter implies an operator
> sequence which is why i ignore concurrency issues.)
Update and delete-insert should be fundamentally different operations
for the following reason. Update deals with object semantics, i.e., how
they are characterized by other *existing* objects. In particular,
update does not change the number of objects and their references.
Delete-insert is a life-cycle management operation that has nothing to
do what objects mean. Instead, it creates or deletes references, which
reflect object existence. As I already mentioned somewhere in this forum
we need to distinguish two layers:
- object semantics (field values), and
- object representation (references).
If they are not separated like in the RM then there is no need to
separate the operations of update and delete-insert (at fundamental
level). Thus in the RM, I agree, these two operations are quite
comparable. But in this case we have numerous problems. One of them is
updating primary key (which has to be disabled in a good model).
However, if we want to separate these two layers then these operations
are fundamentally different.
--
http://conceptoriented.com
Received on Fri Jul 08 2005 - 04:08:45 CDT
