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?