GUIDs (even by newSequencialID) are 4 times are large as INT's and if you are using them as the Clustering Key as well as the primary key, then all of your non-clustered indexes are bigger then they need to be too.
Kim Tripp probably says it best with her article: http://sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx I have used sequential guid's in the past & if there is a lack of good candidate for the clustering key on the table, we put an int/identity on the table purely to serve as the clustered index (ie, the logical DB model does not use the int/identity at all). The down side is that you are "wasting" your clustered index in order to make other indexes smaller. Dave From: [email protected] [mailto:[email protected]] On Behalf Of Greg Keogh Sent: Monday, 6 February 2012 11:28 AM To: 'ozDotNet' Subject: RE: Making an application that uses identity keys occassionally connected Folks, most people here seem to dislike Guids as primary keys. The article<http://www.codeproject.com/Articles/32597/Performance-Comparison-Identity-x-NewId-x-NewSeque> via Bill is quite sobering, showing that NEWID is a shocking performer, but INDENTIY and NEWSEQUENTIALID perform similarly well. After reading that I am unlikely to use NEWID again. I would still like to hear convincing arguments against NEWSEQUENTIALID. Noonie says his DBAs rejected them (why?). Tony hates looking at them in the debugger (that's not a convincing argument for me). Greg L says you might as well get an INT instead (more details?). I hope you'll agree that there are times when you want to give rows an immutable primary key. Will you also agree that an IDENTITY INT is not immutable because it can change when rows move across databases or when rows are reorganised or reloaded. If this is so, how on earth do you stamp your rows with an immutable key without using something like Guids? Greg
