Hello,

I am not shure whether to use assigned guids() as Ids or not. The discussion in the net is wide ranged, from "nogo" to "the one and only". HIA is also not very happy about using assinged instead of surrogates.
On the other hand guids() would be a great advantage for my application.
What are the dissadvantages using assigned guids() with NHibernate?
I found one myself. You won't be able to use the SaveOrUpdate function. Even if I don't have a clue why not. Is this a bug?

Thanks

eg

AFAIK You can, if You use <version> element.

Gert

Thanks gert. But for what is this version Tag exactly for? The documentation says:


Is it just a marker for the Version of this object?

eg

It contains row version number. When update is made, the current value in database is compared to the value in memory. If they differ, someone has changed the row in between, thus the update fails. (Some kind of optimistic locking)

Gert

If you're using an assigned identifier, NHibernate has no way of knowing if it needs to save or update because the ID is already assigned when you pass the object in. Normally SaveOrUpdate checks the Id value of the object against "unsaved-value" and saves if they're equal, otherwise updates.

Thanks to you both. Now I understand that.
What about my main question?


Any ideas?

eg

Maybe they are slower on current 32 bit hardware? No ideas how much, never tested...

Gert

I wouldn't worry too much about performance, as in creating assigned Guid or using guid.comb do pretty much the same thing. In my mind you should only use Guids on objects that you're not creating and deleting very often, and they must have some reason that warrants an upgrade from an integer identifier. Say, a User object is a good candidate for a Guid.

As to performance issues of assigned vs. guid.comb vs identifier, I tend to use guid.comb first, assigned only for a special case like if you want to support import/export of data and want to keep the keys matching for simplicity. I've read a couple articles that make it sound like NEWID() performs a bit better on SQL Server 2005 than on previous versions, but it's still not enough to sell me. Assuming you want your application to be portable to different database engines, my first optimization is to ask "does this really need to be a Guid, why wouldn't an integer work?" and then I'd have to find a compelling argument to make me choose assigned or identifier over guid.comb.

Well, I was talking about integer primary key vs Guid primary key, not assigned vs generated guid...

Gert

Well the performance should not be a problem for me.I want the objects to be loaded once into a singleton repository, where they are cached and delivered. So they are just loaded once per runtime.
Are there other disadvantages concerning NH?

eg