Re: unique constraint instead of primary key? what

gry(at)ll(dot)mit(dot)edu (george young) writes:
> On 9 Feb 2006 08:22:59 -0800
> "BigSmoke" <bigsmoke(at)gmail(dot)com> threw this fish to the penguins:
>
>> If my tables have one or more UNIQUE constraints/indices, I still add a
>> "id SERIAL PRIMARY KEY" field to most of my tables. This makes
>> referencing easier and faster. It also improves consistency, which is
>> never a bad thing in my opinion.
>
> In this schema overhaul I'm trying to *eliminate* arbitrary "id" columns like
> this. They may sometimes improve performance, but certainly obscure the
> meaning of the data -- naive [read-only] users accessing through excel are
> confused by this sort of thing.

Actually, that's not the only people that get confused.

I'm not usually considered overly naive, and there is a database that
I have been using for reverse-engineering purposes of late which is
filled with both "id" and "v_id" columns which *very* much obscure the
meaning of the data.

I'm not adverse to having some such thing; I *am* adverse to giving
them such generic names.

It would be nice to be certain that the "would-be primary key
characteristics" that you'd probably rather use are sufficiently
permanent to be satisfactory. Unfortunately, they often aren't, or
aren't acceptably usable.
--
output = reverse("gro.gultn" "@" "enworbbc")
http://cbbrowne.com/info/oses.html
"To conquer the enemy without resorting to war is the most desirable.
The highest form of generalship is to conquer the enemy by strategy."
-- Sun Tzu, "The Art of War"