tag:blogger.com,1999:blog-2889416825250254881.post6621563715709920438..comments2024-01-27T11:41:32.146+00:00Comments on Byte Rot: Performance series: GUIDs vs. IDENTITY INT in RDBMSaliostadhttp://www.blogger.com/profile/05695786967974402749noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-2889416825250254881.post-42351346953388336992014-04-30T16:21:04.573+01:002014-04-30T16:21:04.573+01:00Thanks for sharing this. It's very helpful. Bu...Thanks for sharing this. It's very helpful. But I miss the foreign key part of the story. Do you use Guid as foreign key too? If the answer is yes, what's the point of having OrderId? Just because it's recommended to have clustered index?Anonymoushttps://www.blogger.com/profile/03383086783675279485noreply@blogger.comtag:blogger.com,1999:blog-2889416825250254881.post-91702240595644488122014-04-25T09:50:11.552+01:002014-04-25T09:50:11.552+01:00Very good article. This is one debate which I have...Very good article. This is one debate which I have been having for the last few years. It makes things pretty clear and GUID is the way to go.Narasimha Rao Tadurihttps://www.blogger.com/profile/10084154108401366496noreply@blogger.comtag:blogger.com,1999:blog-2889416825250254881.post-10921467882926021482013-05-27T20:42:16.323+01:002013-05-27T20:42:16.323+01:00Agreed, developers need to be aware that byte orde...Agreed, developers need to be aware that byte order for GUIDs matters - make sure that the app layer generates GUIDs in the same order as the data layer or else you'll need to write a translation to ensure sequential writes.<br /><br />Be careful of advising DATETIME as clustered index. Ideally a clustered index should be unique. Since we can't guarantee the uniqueness of temporal columns for OLTP applications, we're going to have to create a non-unique clustered index. When you have a non-unique clustered index, SQL Server has to create a uniqueifier value (an INT) as a secret column to make sure each row is unique. You've now got a 2 column clustering key (DATETIME + INT). SQL Server will store a copy of that clustering key with every non-clustered index row. In short - you've added 12 bytes of overhead where a 4 byte INT would have sufficed.<br /><br />Ultimately - when working with anything that puts data on disk, you need to be aware of how you're storing data on disk. That wasted space adds up long term and can be the difference between adequate performance and amazing performance.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2889416825250254881.post-89876734612706993322013-02-11T20:50:49.210+00:002013-02-11T20:50:49.210+00:00Great article I hear this agument a lot from devel...Great article I hear this agument a lot from developers and you've done a great job on highlighting the issues. For the Devs considering generating sequential GUIDs in your application layer (hibernate etc) please ensure the sequence is compatible with how your RDBMS stores them internally. Remember that Sql 2012 now supports Sequences which might help.dfhttps://www.blogger.com/profile/01628372863645744796noreply@blogger.com