Re: Newbie question

In article <11be745cc3crpa1_at_corp.supernews.com>, misha_at_no_mishapen_spam.co.uk says...
> I wouldn't overdo this "optimisation" though -- the use of a surrogate
> key purely to avoid a 2/3-attribute compound key is often a
> pessimisation which makes it much harder to express, and thus enforce,
> constraints such as "the customer to which the invoice applies must be
> the same as the customer to which the receipt applies" which are trivial
> to enforce if we just use (cust_id, invoice_id) and (cust_id,
> receipt_id) as the PKs of the invoice and receipt tables.

I don't really understand the significance of this example, but I agree that you shouldn't design your database so that important constraints are unenforcable. Difficulty of expression is a somewhat different matter, though---but if you can replace multi-relvar general constraints with keys and foreign keys, that is a certainly easier. Anyway, with systems that don't support proper multi-relvar constraints, it is very important.

> Moreover, as Joe Celko often points out, any key that is used in the UI
> should have check digits or similar to catch data entry errors

Why is that? Just to avoid a lookup on the key value?

-- 
Jon