Clark Evans wrote:
>
> > Ok, in multi-version systems readers never lock
> > selected rows and so never block writers. Nice but
> > cause problems in some cases: if you want
> > to implement referential integrity at the
> > application level then you'll have to use
> > LOCK TABLE IN SHARE MODE or SELECT FOR UPDATE to
> > prevent updation of primary keys etc. Not so good...
>
> I was wondering if there is another perspective
> to look upon this problem.
>
> Assertion:
>
> The primary difference between "primary key" and
> "unique key" is that primary keys are _never_ ^^^^^^^^^^^^^^^^^^^^^^^^
> updated (during transaction processing) where ^^^^^^^
> unique keys may be.
1. Is this standard requirement?
2. Note that foreign keys may reference unique key, not just primary one...
3. I told about implementing referential integrity _at_the_application_level_, not by the DB system itself - it's up
tothe user decide what's allowed and what's not, in this case.
> Question:
>
> It seems that the techinical solution here may
> not be better locking, but rather a mechinism
> to prevent updates on primary keys unless the
> entire table is locked, or some other dramatic
> gesture for non-transaction processing.
>
> This leaves the issue of delete looming, so
> mabye the suggestion won't help.
Yes.
Vadim
