Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
sagitariusmzi
Posting Yak Master
113 Posts |
Posted - 2010-02-09 : 07:33:06
|
Hi,Whats the difference between NEWSEQUENTIALID() and NEWID()Does the NEWSEQUENTIALID() doesn't repeat anywhere ?Regards |
|
visakh16
Very Important crosS Applying yaK Herder
52326 Posts |
Posted - 2010-02-09 : 07:37:53
|
newsequentialid function generates unique identifier values sequentiallywheread newid just returns you a unique id value and it may not be in any sequence |
 |
|
sagitariusmzi
Posting Yak Master
113 Posts |
Posted - 2010-02-09 : 07:52:20
|
NEWID() is globaly uniqueWhat about the NEWSEQUENTIALID() ? |
 |
|
visakh16
Very Important crosS Applying yaK Herder
52326 Posts |
Posted - 2010-02-09 : 07:53:58
|
its also globally unique. see http://technet.microsoft.com/en-us/library/ms189786.aspx |
 |
|
Kristen
Test
22859 Posts |
Posted - 2010-02-09 : 08:58:57
|
Note that "Globally Unique" is not absolutely guaranteed to be unique, so you should have a UNIQUE CONSTRAINT / INDEX on all GUID columns "just in case" |
 |
|
ms65g
Constraint Violating Yak Guru
497 Posts |
Posted - 2010-02-09 : 10:14:02
|
quote: Originally posted by sagitariusmzi Hi,Whats the difference between NEWSEQUENTIALID() and NEWID()Does the NEWSEQUENTIALID() doesn't repeat anywhere ?Regards
NEWSEQUENTIALID() use only at DEFAULT constraint. you cannot use it independently.and we can use it for taking newest guid generated in a table. |
 |
|
sagitariusmzi
Posting Yak Master
113 Posts |
Posted - 2010-02-11 : 05:38:51
|
Does the storage affect due to NEWSEQUENTIALID() or NEWID() ?any kind indexes or processing speed ? |
 |
|
Kristen
Test
22859 Posts |
Posted - 2010-02-11 : 06:16:43
|
NEWID() is not good for indexes - randomly distributed and tends to cause page splits.NEWSEQUENTIALID() was introduced to solve that problem, as it is always ascending, and thus indexes can use 100% fill factor.GUID is much bigger than INT, so that affects processing speed.Best to use INT (IDENTITY) unless you need to be able to merge data between servers etc. The fact that you MIGHT need to merge data in the future, or you do it "once in a while" is not a good reason (same as it is not a good reason to use BIGINT for ID instead of INT "just in case there are lots of rows in the future")For one-off merge you can solve collisions of IDs etc., so does not require GUID to avoid that. For merges every few seconds coming from systems that cannot share a single, central, ID-generator, then perhaps GUID is the best solution.For systems where the ID must be generated at the Client (e.g. off-line creation of records) then GUID is an option - but so is adding a "Site" code which can often be TINYINT |
 |
|
|
|
|
|
|