GUID or ID for tables in SPA

Question

Been discussing the merits of GUIDS versus IDENTITY fields as primary keys with my colleagues this afternoon. Coming from a big data background, I instinctively went with IDENTITY but they, who are more web-oriented, preferred GUIDS.

Most of the pros and cons are well documented, and ably summarized here:

http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html

But my co-workers made a point I couldn't answer, and neither could Google, and I thought it was an interesting question. In a Single Page Application style system javascript models (i.e. Breeze JS) are often used to temporarily hold many possible database changes before committing, in order to reduce server round trips. This increases the chance that the IDENTITY field of a table will have incremented due to another insert in the meantime. And that, of course, can cause chaos when you try to commit.

In this scenario then, especially given that SPAs don't generally have performance bottlenecks at the database level, is it generally more sensible to use a GUID instead? Or are we overstating the potential problems of stacking multiple changes to commit?

Answer 1

As Jay says, there is no worry about race conditions with store-generated Ids. Breeze uses temporary keys which are resolved to permanent keys on the database tier. No worries there.

But I generally prefer Guids as well for quite different reasons, influenced by the issues that confront me as a client-side developer with less interest/concern in server-side efficiency.

The best reason for Guids in distributed apps (like Breeze apps) is that offline scenarios are much easier to support. Temporary keys (which Breeze handles quite well) do not survive well when entities are exported and imported ... as they are when storing unsaved new entities in client-side storage (e.g., browser storage). This pattern is useful even if you don't go offline; I often stash unsaved work locally as the user moves through the workflow ... just in case s/he closes the browser accidentally.

To be honest, Guids really aren't much of a problem for you server-side folks. You can beat the fragmentation issue with time-influenced Guids (e.g, GuidComb). Storage and indexing performance issues are diminishing with faster h/w and better DBs. And about the only person who needs to see a surrogate key is a developer; we are paid to suffer.

I write a lot of demos and there is no doubt that using integer identity keys makes that job easier for author and reader. I don't think demos offer sound guidance.

In practice, I use a mix of key data types even if they are NOT identity. My static reference entities (lookups: status, US States, etc) and rarely-changed entities (Products in the product catalog) are typically integer keys. They are easier to read and set (and incidentally store more easily). Entities that a client often creates (e.g., Order) use Guids.

There is no one answer. Your mileage will vary. Insert cliche here.

Answer 2

Not sure if I am answering your question but if you are using identity columns with Breeze then Breeze automatically generates a temporary id value for any new entities before saving them. On the server once "real" ids are generated, Breeze sends a mapping of the temporary to real ids back to the client and fixes up the client ids to match the new "real" ids. Identity value generation is completely handled by the database during the save so there is no real issue with accidentally reusing ids and causing commits to fail when using identity columns. The artifact is that the ids of all of your "added" records ( those that involve identity or server generated keys) will automatically be changed on the successful conclusion of a save.

That said, if you use Guids then none of this is necessary. There is no fixup needed and client ids don't change as a result of a save. Guids do tend to be a bit larger and 'may' exhibit less locality ( thus possibly causing slower saves) than identity columns. i.e. they typically get scattered across the database instead of getting appended to an existing table. ( Sequential Guids partially compensate for this).

Both techniques are viable and have proponents. All things being equal though, I personally prefer Guids. I like simplicity.