>> Disk space is so cheap I suggest you consider the GUID. That way if you have to combine branch offices into a single table, there will be no worries about conflicting integer values. :)
Just to add my $0.02 worth here. GUIDs are generally a lousy choice for primary keys for a number of reasons:
[1] The requirement for a primary key is that it be "
Unique Within a Table". A GUID is (for the next few billion years at least) unique universally. So a GUID exceeds the requirements for a primary key and is bound by rules that have nothing to do with primary keys
[2] The primary reason for using a surrogate primary key is to simplify Joins and speed up processing. Long character strings are NOT an efficient way of doing either - integers are much better for this purpose (which is why all serious database use them)
[3] If you need to merge data I absolutely agree that GUID is the solution - but NOT as the primary key of either the source, or the merged table for the reasons given at [1] and [2] above. The only function of the GUID in a merged table is to be able to identify the source - and the GUID alone (whether it is the PPK or not) is not sufficient for that - you still need to know which source table to look into!
As I say - just my $0.02 worth but this approach has worked for me in all the databases I have ever used (VFP, SQL Server, Oracle, DB2, Informix, Ingres and even in mass-storage systems like TerraData )
Regards
Andy Kramek
Microsoft MVP (Visual FoxPro)
Tightline Computers Inc, Akron Ohio, USA