Re: Surrogate primary key plus unique constraint vs. natural primary key: data integrity?
From: Jan Hidders <hidders_at_gmail.com>
Date: Tue, 19 Mar 2013 12:53:09 +0100
Message-ID: <514851a5$0$26863$e4fe514c_at_dreader37.news.xs4all.nl>
>
> Because surrogates do not carry information, so you can’t write
> constraints based on their values. In practice you may need to replace
> simple check constraints with some SELECT / WHERE constructs (which is
> not well supported).
>
> Because if (a,b) <=> (x) and (b,c) <=>(y) then {(a,b) and (b,c)} is
> not equivalent to (x,y) (you replace a join by a product). So you will
> need some other constraint.
Date: Tue, 19 Mar 2013 12:53:09 +0100
Message-ID: <514851a5$0$26863$e4fe514c_at_dreader37.news.xs4all.nl>
On 2013-03-19 10:00:04 +0000, robur.6_at_gmail.com said:
> On Monday, March 18, 2013 8:22:02 PM UTC+2, Jan Hidders wrote:
>> Why would we need views for that
>
> Because surrogates do not carry information, so you can’t write
> constraints based on their values. In practice you may need to replace
> simple check constraints with some SELECT / WHERE constructs (which is
> not well supported).
Ah, row constraints, yes, agreed. You mentioned foreign keys, so that had me thinking of other constraints. And even if row constraints for views would be possible, they would probably be bad for performance.
>> / And if we do replace composites by surrogates?
>
> Because if (a,b) <=> (x) and (b,c) <=>(y) then {(a,b) and (b,c)} is
> not equivalent to (x,y) (you replace a join by a product). So you will
> need some other constraint.
Agreed.
- Jan Hidders