General information
Category:
Coding, syntax & commands
Thanks for the response. Problem with GUID is size, of course.
What do you think of option 3? Rick Strahl favors that and I respect his knowledge.
Alex
>Option 1 is a nightmare to maintain.
>
>Option 2 is viable as long as replication and offline mode will never be used (now or in the future).
>
>I personally prefer GUID as PK. Easy to generate, no duplication possible, work with replication and offline mode and easy to upgrade to SQL Server.
>
>>I need to decide what to use as PKs for some new free tables. As an example one case involves three tables: Groups, Group-Dates, and Group-Date-Members. The alternatives considered are:
>>
>>1. Use multiple fields as index. In some cases it seems natural because the fields involved have known values. It seems that it would be more difficult to write generic code in the classes.
>>2. Use autoincrementing integer field as PK. Is simplest but I am afraid that if at some future time the next key value is somehow altered up or down problems will follow.
>>3. Some other scheme to calculate integer PKs which offers the possibility of wrapping around and using index values that remain unused. It allows you to freely throw away index values before committing transactions.
>>
>>What is your experience with autoincrementing integers as PKs?
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only