I know I'm a little late getting in on this discussion, however, I thought I would add my 2 cents.

I would never have a primary key with anything that has 'logic' built into it. I always use an integer type and just count up as new records are added (auto increment). The reason for this is that if for any reason your logic changes down the road (e.g. change the name of the branch, change in business names, etc.) it kills your theory, since if you must now change that primary key, you will need to cascade the change to all the foreign key references to it. This is not what you want.

What you want out of your primary key is nothing more than the feature of uniqueness. If you still want to use another value to uniquely identify an entity that has logic in it, then create another column (character type) and make it a candidate key and have uniqueness on it also. This way if this value needs to change due to the reasons mentioned above then you can change it without having to cascade changes throughout the database.

As far as consolidation is concerned, build this using relationships between tables as opposed to values in columns.

HTH


>I am working on an app that will be used in multiple branch offices and then the data from all branches will be "consolidated" into a corporate database. Because of this I need to have a Primary key that will be unique among all branch offices.
>
>I can think of 2 choices the first being the uniqiueidentifier data type, or using a charater type with the primary key being BranchID0000001 etc.
>
>Any pro's or cons thoughts ideas would be welcome