In addition to Bill's thoughts, PK in an archive table *might* need additional column to be part of the PK (this could be, for example, some DATE column).
Because, if our production table has PK on 'customer_id' and we put all that into the archive table every month, primary key constraitn would be violated the second time we try to archive data. Therefore, archive table should have additional column in PK ('customer_id, archive_date').
U need to think about the reason of setting PK .
For eg declaring pk would create an index that might help ur query execution fast on such table....if u try look into execution plans of the queries that run against that table ....
SO u see u r the best person to judge which is a best fit for u .....
But my xperience says since Historical tables are normally huge should have some indexes.
1. I agree with Little foot thought about having composite PK.
2. If you are not having many value of PK of table x in table Y, You can use PK column of x in Y as normal column & you can create a bit map index. ( keep in mind that PK column of x in y should have few distinct value in comparison to data).
I used 2nd approch in one Db & it is working fine till now.