>Hi Naomi,
>
>>>>>Hi all,
>>>>>
>>>>>I just attended a SQL Saturday in Dallas this past Saturday and I got the impression GUID's were not such a great idea for PK's. I would like to understand why that is, and what is the best choice for tables with lots of records.
>>>>>Thanks
>>>>>Tim
>>>>
>>>>Identity int (or bigint) fields are generally recommended. If you insist on using GUID, use NewSequentialID() function to generate them.
>>>
>>>Naomi,
>>>
>>>Can you give me some idea as to why Guid's are no longer the recommended way? There was a day, when GUID's was the recommended key since they were always unique accross all boundary's. An int may be smaller in the db but how on earth would I merge two tables together with an int for the key? I am not advocating either, just trying to get in the know.
>>>
>>>What does NewSequentialID() funchtion do that is different?
>>>Thanks a bunch
>>>Tim
>>
>>Take a look at this blog by George Mastros http://blogs.lessthandot.com/index.php/DataMgmt/DBProgramming/best-practice-don-t-not-cluster-on-uniqu I've asked him to expand it.
>
>Excellent post and it answers my questions. Sounds like I need to modify some things as I have used the UniqueID in all my tables except smaller lookup tables. If I use the NewSequentialID then I will also have to modify some things to get the value back after inserts for my child tables. I appreciate your answers and pointing me to that post.
>Tim

You can generate the GUIDS completely locally for the parent and the children and not have to get the keys from the backend.