Sean Lange (6/26/2013)
Steven Willis (6/25/2013)
So in that vein of thought, you CAN do this but not with an identity column which is of course always and only numeric.Just because you CAN do something does not mean it is a good idea. The whole concept of this is going to be nothing but a complete and total PITA. All kinds of hoops to create the keys, concurrency is a serious concern when you have a table to hold your keys. This thing can and will backfire at some point. It all comes back to what is the gain here?
Sean
I agree that using such an artificial "key" would be a horrible idea and didn't mean to imply that such values should be part of a primary key. But I can see where a computed column approach to create something like an ascending aphanumeric code BASED on an identity value might be useful as part of an employee ID, badge number, or whatever.
Not too many months ago I had a requirement to generate unique registration codes to be handed out to users who would use the code to validate their login. This was a "use-once" code so that the user could login once. The site admins wanted the codes to be sequential because they thought it would be easier for them to administer the codes. I pointed out that if the codes were sequential, anyone with a brain could figure out the sequence from the one authorized code they were given and screw things up. Not to mention the aforementioned difficulties of even doing this as this thread demonstrates. So wisely they took my advice to use random codes.
Now I understand that SQL2012 has a sequential alphanumeric function of some sort, though I haven't seen or tried it yet. So I guess as we all eventually upgrade over the next few years the point will be moot.
Steve