Sequencial Guid

[Guest]

Is there an equivalent class function in C# to generate sequencial guid just
like the NewSequentialID() function in SQL Server 2005?

 

[pbromberg]

Roy,
Since each Guid by definition is completely unique, there could never
be such as thing as a "Sequential Guid". If you need identifiers that
are unique, you should consider using another method. A static double
with an initial value and a method that simply increments this would
do the trick. If it needs to be a string, you can take the ToString()
method on it.
Peter

 

[Nicholas Paldino [.NET/C# MVP]]

Roy,

You can use the UuidCreateSequential API function through the P/Invoke
layer.

For more info, check out the entry on pinvoke.net:

http://www.pinvoke.net/default.aspx/rpcrt4/UuidCreateSequential.html

Hope this helps.

 

[Michael Nemtsev]

Hello Nicholas Paldino [.NET/C# MVP],

hmm, awesome
But why MS desided make guids sequential? Are there any practical reasons
for this?

N> Roy,
N>
N> You can use the UuidCreateSequential API function through the
N> P/Invoke layer.
N>
N> For more info, check out the entry on pinvoke.net:
N>
N> http://www.pinvoke.net/default.aspx/rpcrt4/UuidCreateSequential.html
N>
N> Hope this helps.
N>
N> N>---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Nicholas Paldino [.NET/C# MVP]]

Michael,

They didn't decide to make them sequential, they just gave an
opportunity to generate them should people need them? I would NOT use these
if I needed to create a unique number, but only if I needed to create a
sequential 128-bit number.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello Nicholas Paldino [.NET/C# MVP],

hmm, awesome But why MS desided make guids sequential? Are there any
practical reasons for this?

N> Roy,
N> N> You can use the UuidCreateSequential API function through the
N> P/Invoke layer.
N> N> For more info, check out the entry on pinvoke.net:
N> N> http://www.pinvoke.net/default.aspx/rpcrt4/UuidCreateSequential.html
N> N> Hope this helps.
N> N>---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do
not cease to be insipid." (c) Friedrich Nietzsche

 

[Peter Duniho]

Hello Nicholas Paldino [.NET/C# MVP],

hmm, awesome But why MS desided make guids sequential? Are there any
practical reasons for this?

One common use of sequential GUIDs is when you have a bunch of COM objects
that are all related and you want an easy way of organizing them. Even if
all that means is that they show up next to each other in the registry,
that's sort of useful. There may also be some purpose to being able to
quickly convert from a GUID to a 0-based index.

I suppose one could debate the exact degree of benefit from that sort of
thing, but the fact remains that those are possible reasons for wanting GUID
in sequential order.

Pete

 

[Sericinus hunter]

Hello Nicholas Paldino [.NET/C# MVP],

hmm, awesome But why MS desided make guids sequential? Are there any
practical reasons for this?

One common use of sequential GUIDs is when you have a bunch of COM objects
that are all related and you want an easy way of organizing them. Even if
all that means is that they show up next to each other in the registry,
that's sort of useful. There may also be some purpose to being able to
quickly convert from a GUID to a 0-based index.

I suppose one could debate the exact degree of benefit from that sort of
thing, but the fact remains that those are possible reasons for wanting GUID
in sequential order.

Also, having a clustered index on GUID column in the database table
makes more sense if it is sequential.

 

[Gordon Smith \(eMVP\)]

Keep in mind though, that you aren't allocating multiple UUIDs in one call
to the OS. Therefore, you could have conditions where other
threads/processes are also calling the same API thus making your results not
a contiguous set of "numbers".

Michael,

They didn't decide to make them sequential, they just gave an
opportunity to generate them should people need them? I would NOT use
these if I needed to create a unique number, but only if I needed to
create a sequential 128-bit number.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello Nicholas Paldino [.NET/C# MVP],

hmm, awesome But why MS desided make guids sequential? Are there any
practical reasons for this?

N> Roy,
N> N> You can use the UuidCreateSequential API function through the
N> P/Invoke layer.
N> N> For more info, check out the entry on pinvoke.net:
N> N>
http://www.pinvoke.net/default.aspx/rpcrt4/UuidCreateSequential.html
N> N> Hope this helps.
N> N>

Is there an equivalent class function in C# to generate sequencial
guid
just
like the NewSequentialID() function in SQL Server 2005?

---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do
not cease to be insipid." (c) Friedrich Nietzsche

 

[Dave Sexton]

Hi,

I don't think so. I thought the point of a clustered index was to order the data rows against the index. The index is sorted no
matter the type of the column or the values that it contains.

--
Dave Sexton

Hello Nicholas Paldino [.NET/C# MVP],

hmm, awesome But why MS desided make guids sequential? Are there any practical reasons for this?

One common use of sequential GUIDs is when you have a bunch of COM objects that are all related and you want an easy way of
organizing them. Even if all that means is that they show up next to each other in the registry, that's sort of useful. There
may also be some purpose to being able to quickly convert from a GUID to a 0-based index.

I suppose one could debate the exact degree of benefit from that sort of thing, but the fact remains that those are possible
reasons for wanting GUID in sequential order.

Also, having a clustered index on GUID column in the database table
makes more sense if it is sequential.

 

[Sericinus hunter]

Hi,

I don't think so. I thought the point of a clustered index was to order the data rows against the index. The index is sorted no
matter the type of the column or the values that it contains.

This is true. But GUID by itself does not make sense of being sorted.
If you create a clustered index on GUID column then you will likely
see more page splits during insert operations than you normally want,
because new rows will have GUID values all across the range of existing
values. With sequential GUID this can be avoided. I think that was the
primary reason for introducing sequential GUIDs.

 

[Dave Sexton]

Hi,

I don't believe that it makes more sense to have sequential guids as the values in your column, however I do believe it's required
to have the values sorted in a clustered index. Because of that requirement the DBMS will sort on your column, so I don't think it
really matters whether the values appear sequentially in the table.

In SQL Server, there is no mention in the documentation about sequential guids and there is no function AFAIK that will create them.
When inserting rows into the table with that column, one usually uses the newid() function to populate it, which does not produce
sequential guids. When you create a unique clustered index on a uniqueidentifier column the index will sort on the values in that
column, and because of its clustered nature, the data rows will be sorted based on the sort of the index.

Now, if I'm mistaken on any part of this please let me know. I don't claim to be an expert on this, and I really don't understand
your reasoning.

 

[Sericinus hunter]

Hi,

I don't believe that it makes more sense to have sequential guids as the values in your column, however I do believe it's required
to have the values sorted in a clustered index. Because of that requirement the DBMS will sort on your column, so I don't think it
really matters whether the values appear sequentially in the table.

In SQL Server, there is no mention in the documentation about sequential guids and there is no function AFAIK that will create them.

There is. They introduced it with SQL Server 2005.

When inserting rows into the table with that column, one usually uses the newid() function to populate it, which does not produce
sequential guids.

And now you can use newsequentialid() function. Although it works only
in default constraint declarations.

When you create a unique clustered index on a uniqueidentifier column the index will sort on the values in that
column, and because of its clustered nature, the data rows will be sorted based on the sort of the index.

Yes, but here how it works during inserts. With clustered index,
the data row must physically go to right place in the storage because,
as you correctly said, the whole row, i.e the data itself is sorted.
Now imagine that a new row is inserted and its GUID value is somewhere
in the middle of the range of already existing (and sorted) rows. This
is very likely due to random nature of GUID. The row goes in the middle,
and all the rows from that point to the end must be physically rearranged
on the disk. Performance-wise this can be very costly. With sequential
GUID on the other hand, you always add the row to the end of physical
storage, thus making inserts much more effective.

 

[Dave Sexton]

Hi,

There is. They introduced it with SQL Server 2005.


And now you can use newsequentialid() function. Although it works only
in default constraint declarations.

Interesting. I searched for "sequential" alone and in combination with other terms before I wrote my last post, and that function
didn't show up in any of the results (SQL Server 2005 Help System: Local and MSDN). Also, documentation for the standard functions
and keywords such as uniqueidentifier, newid() and ROWGUIDCOL in the column definition topics and CREATE TABLE topics do not link to
that function, at least not directly. And as a matter of fact, they all still recommend to use newid().

Thanks for the info.

Yes, but here how it works during inserts. With clustered index,
the data row must physically go to right place in the storage because,
as you correctly said, the whole row, i.e the data itself is sorted.
Now imagine that a new row is inserted and its GUID value is somewhere
in the middle of the range of already existing (and sorted) rows. This
is very likely due to random nature of GUID. The row goes in the middle,
and all the rows from that point to the end must be physically rearranged
on the disk. Performance-wise this can be very costly. With sequential
GUID on the other hand, you always add the row to the end of physical
storage, thus making inserts much more effective.

Thanks for the explanation. Your original statement is much clearer to me now.

 

[Noah Sham]

Is the primary access going to be by guid? If not, you might want to create
the primary key index nonclustered and create a clustered index on an
alternate key (assuming the table has an alternate key).

 

[Sericinus hunter]

Well, yes, choosing on what columns to create a clustered index on is
a completely different issue. Personally, I believe that building it on
a GUID column is rarely a good idea.
And it is not necessary to build it on key columns, any column(s)
can be candidate.