Thanks,
Bernhard Kircher

I know seems like I’m looking at the problem from the DB’s perspective, and that if I’m using an ORM I probably shouldn’t even care about this. I just want to make sure I actually get all of this.

That said, from an architectural point of view, I vastly prefer GUIDs to IDENTs for my primary keys. I discount the most common argument against GUIDs, which is the whole “what if I’m trying to troubleshoot the DB and I have to type in this whole big nasty GUID rather than a simple WHERE ID=12345?” argument. COPY AND PASTE, people!

The people who say “well, what about the ops folks being able to say “that’s an issue 144′?” I just want to smack upside the head. USE NATURAL KEYS, people!

I just wanted to add some information on Guid generation within Code. As mentioned in the article on NHibernate, Guid.NewGuid() is not the best idea because of fragmentation, and therefore causing more IO and so on. The Guid.Comb seems to be a good idea (depending on it’s implementation). I just wanted to add, that if you are using MS SQL server, you can generate the Guids in your code the same way the server does when calling newsequentialid(). It uses the rpcrt4.dll. The generated guid has to be edited, because of the way sql server is sorting them. I added more information here (with more links to my resources)
http://stackoverflow.com/questions/170346/what-are-the-performance-improvement-of-sequential-guid-over-standard-guid/1042719#1042719

best regards,
Bernhard Kircher

Thanks for reply.

That makes a lot of sense (the OrderCodeGenerator). I guess I was blinded to the idea that the hi-lo is an algorithm, not just an option in NHibernate :)

So that OrderCodeGenerator would not only abstract away the process but if it implemented the hi-lo algorithm would remove the database lookup per order creation (although it definitely could have a db request if done lazily on the first one, or if it ran out of lo’s, etc).

I dream about one day not having my crappy db, and that was the latest thing on my mind of “how would I do that” :)

Assigning a human-friendly identifier to entities (“order number”, “customer number” etc) is a separate business requirement and doesn’t have to inform or conflict with your choice of PK data type. Bear in mind the requirement could easily extend to something other than a sequential integer, e.g. some kind of “meaningful” prefix.

This requirement isn’t that awkward to implement. You have some kind of strategy – IOrderCodeGenerator.Assign(Order order) or something – to generate the codes. A database will have to come into play to generate the sequence, but the hi-lo algorithm “reserves” a number of keys in a sequence within a single database call. This approach won’t interfere with batching at the ORM level.

We have some tables at work that deal with parts. A part number is the key of that table. This has caused a ton of problems. The thing that makes it suck is (a) users actually key this in and (b) a part number has a ton of meaning outside of the database. The part number, once entered and used, no matter how wrong or how many good reasons there are to change it, can no longer be changed without breaking all FK relationships. It sucks.

What sucks even more is that natural key such as this (part number) just lead to composite key (serial number? oh that is unique per part …. so serial table is PK of serial # and part #… ugh).

Sorry for just thinking out loud here — it is just that at first glance it is absolutely clear to me that guid.comb is wonderful… decision done, one less thing to worry about, check mark! But now I am doubting or questioning at least.

I totally agree with the first half — I’m not saying Order 1097820 should be the PK. I want a guid PK, but I want to keep a unique number to be able to reference it by for humans. Like you say a unique constraint on that column in db.

What sucks is that the benefits of a GUID (or any generated id) is that the ORM can generate the field and save round trips and allow batching. BUT when I now want a seperate unique key as an integer for humans, I have no idea how to generate that WITHOUT somehow working with the database (I’m not saying its impossible, just I have no idea how to do it).

I am wondering if any tips/tricks exist for this: how to generate a unique (non-PK) key for an entity w/out requiring that extra database trip to either (a) generate the key or (b) verify that it truly is unique.

a coworker responded via company email. i thought his response was worth sharing. you can read it here:

http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/storage-size-and-performance-implications-of-a-guid-pk.aspx