Peterson, Andrew S. wrote:
>
> I've got four columns that can be used as the primary key. I also have a
> uniqueIdentifier field (I'm using SQL Server) that I generally use as a
> primary key for my tables because it's so easy. It seems like it would
> be four times as much work whenever I utilized the four fields that make
> up the primary key rather than just using the uniqueIdentifier,
> regardless of what scope I place them in (URL, Form, etc.) or how I use
> them (where clause, procparams, etc.).
>
> Instead of using the uniqueIdentifier as key, could/should I create the
> primary key based on the aforementioned four columns?

You could. Whether you should depends on many issues, the most
important one being that often a (combination of) field(s) which
appears to be suitably unique and unchangeable at a first glance
does not qualify when scrutinized more closely.
Then there is the performance issue and the 'more code' issue.

What is the actual content of the 4 fields you think qualify?

> If so, would the
> uniqueIdentifier field have any use, or should I just get rid of it?

If you go that way, get rid of it.

Jochem
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to