>>>Hi,
>>>
>>>For me I normally set the length only base on my estimation on how large the table probably will grow.
>>>The larger the lengthier, things like 10, 12, 16, 24 or even 32 chars in length.
>>>
>>>I wonder what are the key factors everyone else is considering when trying to determine the length of a GUID field (let say it is used as primary/surrogated key field of tables).
>>>
>>>Is there any good article out there discussing how should one decide the length of a GUID field (be it a sequential one or non-sequential)?
>>
>>c(36) works best in my experience (but maybe because I work with SQL server a lot). Perfromance would be affected is a myth IMHO. Search for COMB keys on the internet for details explicitly related to SQL server.
>
>
>Cetin, in VFP performance is affected by the length of the key. I made testing last year, an decided to go with integers just because of this. In MS-SQL it might be another story, I don't know.
>
>And for the ones who say "storage is cheap these days" just would like to add: this is the one of the paths to make bloated software, just like "performance is not such an issue as in the past due to new processors".
>If you keep relaxing you will produce more a more bloated software.

Unfortunately you can't exchange GUIDs with integers for many reasons (GUID itself is an integer but I mean 32bit integers).

Anyone who cares about storage bloating wouldn't even use DBF. DBF is one of most storage wasting structures (not as worse as XML but tons of unused space).

Cetin