Newsequentialid error validating default mixed messages dating
If you care to ask around your colleagues, it's almost guaranteed that you'll get multiple conflicting opinions on why you should or should not use GUIDs in SQL Server, but few developers actually realise the impact of such a design choice.In the interests of science, I'll try and keep this as factual as possible, and I'll focus on the topic at hand, rather than GUIDs / UUIDs in general.The above table also helps when comparing the size of UNIQUEIDENTIFIER, INT and BIGINT based indices.It's obvious for reasons already mentioned that a UNIQUEIDENTIFIER will use more space than an INT or BIGINT, and whilst the numbers in the Index Size column above are tiny for now, their sizes will increase considerably when more columns are included or referenced in the index.I've spent many years debating with my fellow developers across all manor of subjects (I do love to talk), but one subject that comes up time and time again is the usage of the UNIQUEIDENTIFIER data type in SQL Server; especially when they're used as identity and key columns.In fact, I see this more often than you would expect, and misconfigured UNIQUEIDENTIFIER columns can create "hidden" problems that can be difficult to discover and / or rectify, depending on the SQL experience throughout your team.Rows Reserved Space Actual space Index Size Unused Space My Int 1,000,000 12,936 KB 12,864 KB 56 KB 16 KB My Big Int 1,000,000 16,904 KB 16,808 KB 88 KB 8 KB My Guid 1,000,000 34,760 KB 34,552 KB 160 KB 48 KB My Guid Seq 1,000,000 24,968 KB 24,768 KB 176 KB 24 KB And now the critique... BIGINT columns have a numerical range of -2^63 to 2^63, taking up 8 bytes.
Not much on its own, but consider that a table is likely to be much larger than that, and using the column as a foreign key in other tables means your storage requirements will rapidly expand.There is a lot more to database design than initially presents itself; I remember learning all about normal form at college, which - whilst important - doesn't prepare you for all the funky under-the-hood mechanics that goes on in the real world.I won't go into any more detail here, as there are hundreds of articles out there explaining fragmentation and at what point you should reorganize or rebuild an index.A while back I also wrote a script to assist with automated index management which I still find quite handy, though it should be noted that the more complex your database, the more specific you should be about individual indices.The only thing that's left for me to say on index fragmentation is this: if you absolutely must use a UNIQUEIDENTIFIER as your primary key (you don't, btw), then ALWAYS use NEWSEQUENTIALID() over NEWID().
The following SQL will give us stats on all four tables: name Fragmentation Percent fill_factor page_count PK__My Guid Se__3214EC276477ECF3 0.71 0 3096 PK__My Guid__3214EC275FB337D6 99.08 0 4343 PK__My Int__3214EC275812160E 0.44 0 1608 PK__My Big Int__3214EC275BE2A6F2 0.48 0 2101 There's a tiny amount of fragmentation on the INT and BIGINT tables, and a little bit more for UNIQUEIDENTIFIER when NEWSEQUENTIALID() is used, but as you can see, the My Guid table (which uses NEWID() as the column default value) is almost 100% fragmented. Fragmentation slows down the retrieval of data from the table, meaning the SQL query engine has more work to do when it needs to scan the index. Well, NEWID() produces a pseudo-random GUID which is pretty much unpredictable, and 100% non-sequential.