Like I said, if you never plan to use replication or offline mode, integer PK may be a good choice.

Unless you plan to have tables with millions of records, I don't think that the size of GUID should be such a big deal.

See also: http://stackoverflow.com/questions/262547/reasons-not-to-use-an-auto-incrementing-number-for-a-primary-key

>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.
>
>>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?