Re: What do you do with an ENORMOUS primary key?

>
> Mmmm. Thanks. Interesting that both you and Neill see a synthetic primary
> key looming over the horizon. I don't think that will work, because then
> there's no guarantee that you won't schedule a rose bush to be pruned twice
> in one day -and a poor looking specimen it would be then!! I've never liked
> synthetic keys (like Microsoft's autonumber) for just that reason: it's
> every appearance of primary-keyness, but doesn't actually guarantee
> uniqueness for your real data. But that's a philosophical discussion that
> can run and run, I think!
>
> But thanks anyway for thinking about it.
>
> Regards
> HJR
I take your point, but personally I do like surrogate primary keys. I recently worked on an application with a table of customers. What do you do then? Name? Obviously not. Name and birthdate - still not a guarantee of uniqueness. Social Security (NI in the UK) number - maybe, but not available in this case.

Even if you could get uniqueness, you could have some pretty horrendous foreign keys, which is probably my main reason.

I guess what I'm saying is that you have to be flexible, and do what is best for the individual application. Personally though, I'd have a surrogate primary key and a unique index on the logical primary key.

CE Received on Fri Jun 21 2002 - 05:59:00 CDT