Re: Preferred method in creating primary key

Brian Peasland wrote:

> It makes some sense that this index is not unique since the constraint
> checking is deferred until you commit. Before the commit, you are
> allowed to insert all the duplicate key values you want, but you must
> remove them before you commit. If the index were UNIQUE, then the
> duplicate key values would not be allowed.
>
> Personally, I've hated deferrable constraint checking since it was
> introduced. We put constraints in the database so that the business
> rules on the data are adhered to. This is especially important since we
> don't trust the application to validate those business rules for us. So
> why do we decide to throw out those business rules "temporarily"? It
> just seemed to me to be a short cut for doing things right the first
> time. Maybe it's just my opinion though...
>
> Cheers,
> Brian
>
> <snipped>

I agree with respect to primary key and unique constraints. They make no logical sense. But they are a logical extension when applied to Foreign Keys.

--
Daniel Morgan
http://www.outreach.washington.edu/extinfo/certprog/oad/oad_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)