Primary key choice 1

[Niv3k]

I will be creating a table that will have three or four columns acting as a primary key, depending on whether or not 'DLCI' (the fourth column) is null or not. Problem is, as I run automated imports, I will be adding and deleting a lot of records, so an identity column is not a good idea. BUT - I can't have three columns be the primary key, because some of the time the fourth column will be null (the first three are unique), other times, the fourth column will have data (in which case the first three colums will have duplicates)

I thought about using a Unique Identifier for the primary key, but wasn't sure about speed for queries, efficiency, etc. I also thought about a calculated field for a primary key, but, again, not sure about speed and efficiency.

I am running SQL 2000. Any suggestions? (The database is still on paper, so my options are pretty open)

Kevin

 

[fluteplr]

What was the problem with an identity key. Adding and deleting records will not affect that. If you think you will run out of numbers use a bigint instead of a integer.

 

[Niv3k]

Well, see, there you go. I wasn't aware you could use a bigint for an identity key. I just went from 6.5 to 2000, and I like it a lot better than 6.5. On 6.5, you could only use an int. Thanks!


Kevin