Sequential Guid Identifiers

76 views
Skip to first unread message

Matt Johnson

unread,
Mar 22, 2012, 2:20:33 PM3/22/12
to ravendb
First - I understand that Oren doesn't like Guids. That aside, if I
DO choose to use Guid identifiers, does it matter if I create
sequential Guids using something like the CombGuid strategy, or if I
just use Guid.NewGuid()?

I understand that in SQL Server, the Guid as the primary key can cause
bad page fragmentation if you don't use sequential guids. I'm not
sure that Raven would suffer the same issue or not?

Thanks,
Matt

Oren Eini (Ayende Rahien)

unread,
Mar 23, 2012, 3:02:26 AM3/23/12
to rav...@googlegroups.com
No, it doesn't matter. We don't really use the key as the clustered index, anyway.
Note that my main objection for Guids is that they are not human readable.

Matt Johnson

unread,
Mar 23, 2012, 10:52:06 AM3/23/12
to ravendb
Thanks for the info.

I agree about readability of guids, but hilo doesn't solve the problem
in many cases.

In my case, I'm implementing CQRS pattern where commands are sent by
the client ui. An initial "create person" command might be followed
by several "do something with this person" commands before the query
store is ever updated. It's important that the "create person"
command itself is responsibile for ID generation before the command is
sent, such that the ID can then be used in the subsequent commands.
In other words - raven is not around yet to provide the key.

var cmd1 = new HireEmployee { Name = "John Doe" };
var cmd2 = new AddEmployeeToGroup { EmployeeId = cmd1.EmployeeId ,
Group = "Sales" };
_bus.Send(cmd1,cmd2);

I would have to move the hilo generator into the client ui somehow,
detached from raven. It's easier to just get a new guid (done in the
constructor of HireEmployee).

Any better suggestion?

Thanks,
-Matt

On Mar 23, 12:02 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:

Oren Eini (Ayende Rahien)

unread,
Mar 23, 2012, 10:59:19 AM3/23/12
to rav...@googlegroups.com
a) do hilo on the client
b) use the guid as just the starting point, correlation id, not the actual id.

Chris Marisic

unread,
Mar 27, 2012, 2:09:56 PM3/27/12
to rav...@googlegroups.com


On Friday, March 23, 2012 10:59:19 AM UTC-4, Oren Eini wrote:
b) use the guid as just the starting point, correlation id, not the actual id.

Fields are absurdly cheap with RavenDB, I have CorrelationId on every single document that gets stored into Raven. The way I view it is I can never go wrong having a true Guid key assigned to every single document in addition to business/human meaning identifiers.
Reply all
Reply to author
Forward
0 new messages