Developers resort to use “RefRecid” as foreign key that when they don’t find a natural primary key. But there is one another option that developers can evaluate before settling with RECID. That’s the GUID field. GUID’s are 16 byte unique identifiers that are unique across db’s unlike the recids and can be generated by the newguid() function.
Here are some of the Pro’s and cons associated with using GUID as Primary key’s.
-> Unique across db’s. This makes merging db’s/tables easier
-> Easy upgrade. Unlike Recid’s the GUID’s remain same after upgrades and doesn’t require any special code to handle.
-> Generation can be controlled. With GUID’s you can make the choice to insert it at any point of time unlike the recid’s. Either before insert or after insert.
-> Unlike natural keys these don’t change. The foreign key relation can be retained with ideally no change to the primary key.
-> Twice larger then recid, but SQL guru’s indicate that it matters less with good optimization for guid’s after SQL 2005.
-> Debugging can be cumbersome
-> You can’t order them as they are not sequentially generated. (SQL has a way for sequential guid’s but I doubt if it is there in Ax also).
This doesn’t mean that “GUID” is the way to go but that’s another option to evaluate when you make the choice. Read this article to know how to make the choice http://bit.ly/fRwJpn
In standard Ax you can find the extensive use of GUID’s in the AIF related tables.