jwcolby
jwcolby at colbyconsulting.com
Thu Jun 25 12:48:55 CDT 2009
>> A reason to not use a Guid is ressources. It takes a little more space It takes a LOT more space. An autonumber takes 4 bytes, a guid takes 16 bytes. That is 4 times the storage for each PKID. Furthermore it is much slower as it is a string of CHARACTERS and thus comparisons require string manipulations instead of just comparing two longs in a register. String comparisons are always functions in libraries, vs a simple register to register compare (a single X86 instruction). John W. Colby www.ColbyConsulting.com Gustav Brock wrote: > Hi Shamil > > As Jim tells, if you can't guarantee that your object will live at one location only and can/may be mixed with similar objects from elsewhere, use a Guid to identify it. As I'm sure you know, in Access this has been available since A97 (or A95?) where replication was introduced. > > A reason to not use a Guid is ressources. It takes a little more space and - random as it is by nature - you will most often need other keys for sorting, a timestamp for example. > For one project I mixed this. Simplified, a Guid was used for the Company table, while all other tables in some way related to the Company table and could use a normal Autonumber. > In another project I (again simplified) used a compound key for the Company table (or the the object identity) with one field to identify to location and one field with an Autonumber. If this is what you have in mind, you are of course right, that the single Id autonumber must be given up. > > /gustav