> >> 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, USAWell they say if you ask 10 computer experts a question you'll get 10 different answers. Unfortunate for all of us, IMO.
#1 does not disqualify it.
#2 I agree with except that more and more serious database people are using GUIDs
http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.htmlhttp://www.informit.com/articles/article.asp?p=25862&rl=1#3 Not for a merging - I'm talking more about a corporate merger. If branch A had a completely different set of customers than branch B, the use of numerics in each branch would absolutely require our intervention. With GUIDs we could just append one set of customers to the other.
Mike Yearwood
www.foxridgesoftware.comPresident: Toronto Ontario FoxPro User's Group