Unique Keys versus IDs in Web Applications

An ID is a fine way to uniquely identify an object, the common usage is also very user un-friendly. A while back I was watching a presentation by Jeffrey Palermo on Community For MVC.Net, then later at a live presentation and discussion at the local user group in Cedar Rapids. Not that it’s a new idea, but the idea of a Key and the IKeyable<T> interface was mentioned. This idea being a unique, human readable string. Throughout the rest of this post, when I mention “ID”, I’m speaking of an auto-generated number or meaningless string. When I mention a “Key”, I’m speaking of a meaningful string identifier that gives some sense as to what it is representing when a human reads it.

IDs in an Web Application

Sequential integers in a database are easy to come by and are guaranteed to be unique by the database. This makes things simpler since you’re not required to check for uniqueness. Another option is to use GUIDs. These are good because the chance of collision is extremely small and gives you hundreds of billions of combinations. Another unique ID that I’m seeing appear more recently is the incremented strings, where “ab89Fh” is the prior ID to something like “ab89Fg”. All of these solutions are great for keeping things unique from the data perspective, but are horrible for human memory.

Unique Keys in an Web Application

The concept is simple: a human-readable key that uniquely identifies an object. Why is a unique human-readable key a good idea? A key that is generated from some meaningful text is likely going to exist within a URL when in a web application. This is good for many reasons:

  1. They’re easier to remember
  2. Search engines see them as text and not garbage.
  3. You can make some assumptions as to what the content is, given the key.

Use keys over (or in conjunction with) IDs. They’re nice, they’re good and you’ll love them.

More Resources

About Chris Missal

Oh hey, I'm a Senior Consultant for Headspring in Austin, TX. I've been working in software professionally since 2006 and I really, really love it. I'm mostly in the Microsoft world, but enjoy building computer things of all sorts (to be vague). When I'm not slinging code, I'm probably out and about slinging discs, bowling balls, or good beer with great friends.
This entry was posted in Best Practices, Development. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Chris,

    I’m quite interested in your comment about numeric ID’s not being memorable. I don’t believe that’s so. I don’t believe this for two reasons: I’ve observed the contrary, and the things that cause memory imprinting are not inconsistent with numeric ID’s. Memories are made by either repetition or by significance.

    Users tend to work with some data more than others. They tend to remember the ID’s or codes that act as mnemonics for these data. It can take some time to imprint these memories, but they are often sooner or later made. A user will also remember a datum when it’s significant to their work. For example, we remember the project codes and job codes for the work we usually do and record into time tracking and billing apps.

    Ultimately though, we shouldn’t be creating user experiences whose successes are predicated upon remembering data identifiers. We shouldn’t even be having this conversation as an issue of usability of identifiers. If we’re talking about this as a usability issue, then we’re far from the root cause and we’re merely tweaking the manifestations rather than the source.

    Case in point: I don’t remember the identifiers for articles I read on the web – whether they’re identified by a date-based ID or by a textual slug. Neither of these identifiers imprint memories unless I explicitly work to create the memories. I can, however, use the particles of memory that I do have about an article and search for that article.

    On the issue of SEO, the text of the link is valuable for ranking, but ranking is only an issue when using general, open searches like Google. If I remember the application or website that owns the data that I want to use, then I’m not confined to general, open searches. I can use the application or website’s own search features. If those features don’t exists, then we may have a root cause issue to look at in that case.

    Lastly, I find it extremely disheartening that the .NET web community is still trying to deal with these kinds of implementation issues. Better, more mature web platforms have offered direct support for these kinds of things for a number of years. I sincerely wish that there was more open, best-of-breed thinking in this community. Especially because the adopters of ASP MVC were supposed to be the open-minded, best-tool-for-the-job people. I’m just not seeing that trait expressed anymore. It really just appears that the goal is to continue to use .NET at all costs, even when it’s more costly to do so and when there are platforms available that show .NET web platforms to be rather crude and primitive.

  • Scott,

    You bring up some very good points. I would say that I can remember numbers fairly well when associating them with a single idea or another value. Things like zip codes, area codes, addresses, birthdays, and so on. I see the problem with web sites that use these numbers as a way to access content. Sites that serve up images or file downloads are hard to search if they don’t have much for text content. Unfortunately I find that this is often the case. In other words, I can’t think of a single web page or article or anything to which I know the content that has an address like http://www.sample.com/705.

    If those sites did have great content and I could find anything I wanted to with ease, there’s still the need for many web sites to attract new visitors through an open search like Google. They put a lot of weight on the URL (along with the title and h1 tags), so you’re going to lose some relevance by not putting some text there, along with, or instead of, those numeric values.

    While sharing my ideas here, I’d love to write about ideas and thoughts on the best of the best. I do nearly all of my work within MVC for my company, so my writing is usually within the .Net and ASP.NET MVC space. I never expect to give an ideal post to everybody, but if there are some readers out there that can benefit from this, I’ll be happy.

  • Personally, I think that many more people could have much more happiness if they could be guided through the fear that blocks them from using more mature and user-friendly web application development platforms. There’s undoubtedly value in clarifying the use of ASP MVC, but there’s quite possibly even greater value in beginning the work to transition away from it. If the goal is goodness and happiness, then we shouldn’t really entertain such arbitrary constraints. After all, there was a time years ago when we had to fight to transition companies on to ASP .NET. We have nothing but countless precedent that shows that the same thing can be done again.

  • PS:

    Regarding your response to Annie:

    > @ajepst agreed, but as a shopper, i’m not going to look for them in the
    > number coded aisle since I don’t know the numbers

    The cognitive processes involved here are predicated more on graph traversal and specialization than on identification. In this case, the usability design is quite a bit more involved than creating mnemonics.

    You’re not using direct access when narrowing down the location of vegetables, you’re using relative access. Mnemonics are direct access mechanisms. These two different kinds of scenarios are polar opposites of each other in respect to usability design.

    There are specific contexts where direct access mechanisms are useful to a general population of users, and when they are, they’re rarely served by a mechanism like an browser’s address bar.

    Again, the great benefit of semantic resource addresses is SEO. And it’s fine to make use of them then, but semantic resource addresses aren’t a boon to usability. In any scenario where they might be useful, more terse mnemonics almost always serve the user better.

  • Sean

    @Scott — while I’ll admit there are “more mature and user-friendly web application development platforms” out there, I fail to see how this translates to entertaining “arbitrary constraints”.

    Yes, folks should be encouraged to look outside the .NET domain, but by the same token, what is wrong with encouraging them to look within it? I don’t see an issue with some folks promoting the n-stack and other promoting alternative and possibly more mature, better, way easier to use stacks.

    Why does goodness and happiness == not using .NET? Or to put it a different way, what is wrong with folks using a possibly less mature, inferior, harder to use technology if they *want* to?

    Personally I think that people will be much happier if they are given options and allowed to make their own choices, rather than guided towards any particular web development platform. If I want to use ASP MVC I’ll look for guidance specific to it, if I want to use Spring or ROR I’ll look for guidance specific to them.

  • MC

    We use GUIDs in our current project, because the database generated keys are only unique to that instance. When it will late become necessary to merge databases, we’d have a huge problem. A key server has been discussed, though.

  • Nicolas

    The problem with key that are meaningfull is that the sooner or later, you data model will change.

    So the textual key will not be unique or usefull anymore…

    And maybe you’ll change the title, naming of an item in your database (bacause of a typo for exemple). If the item is identified by a number, it will not change. If the ID is made with the item label or name, then the key will change.

    It not so good for user, but very very bad for you software. More more mantenance cost, higher risk of bugs and all.

  • J

    This is called Surrogate keys (autogenerated, no business meaning) vs Business keys.

    Surrogate keys are widely accepted and considered as a best practice in enterprise programming, because of:
    -flexibility when requirements change
    -db merging

    Your database design shouldn’t suffer because of SEO decisions, it should be independent. If you need business keys for your webapp, you can take candidate key and put some unique constraints on it.

  • You could have provided an example of a human-readable key in a web application as the last part of the URL of this very post ;)