• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 258
  • Last Modified:

"Unique ID" server for multi-server app

I'm building an app that I hope will scale to need multiple servers.

For certain objects, I'd like to provide users with an "External ID".  This would be either a user entered or randomly generated string, like  "Fred's Data" or "q1g52xTK".  This external ID would be associated with a GUID, and would allow the user to get at the object without having to know the GUID (such as at log-in).  (They will also be able to select via more complete names, titles and descriptions.)

For each new external ID,  I'll have to do a lookup against all existing external ID's for that object type, to make sure it's not been used.

I'm looking for design patterns for how to accomplish this.  

I'm assuming one such pattern would be to put an "ExternalID_Master" table in one DB on one server, and to accesss and maintain this table through a webservice that could be called from different instances of the app on different servers.   Also, I'm assuming that I could build the methods for the ExternalID_Master table access and maintenance into the "core app", and migrate them to the webservice when needed, as part of the first "multi-server" release.   (And maybe add some redundancy via multiple copies of the ExternalID_Master on different servers...)

It may be as I explore this I'll find myself learning about how ASP.NET apps and their SQL companions are scaled and distributed to multiple servers...for now I'm wanting to find a path that will work at all for the "ExternalID" issue, so I can make sure to incorporate it into the design, development and deployment plans.

Any guidance on these matters would be appreciated.


  • 2
1 Solution
the idea of a seperate table with just GUID's associated with a specific users is probably one of the better solutions. However, if all the data is being stroed on the same databse server, you do not have to worry about the DB repeating GUID's, it won't happen. If you have several DB servers, then one central table me be the way to go.

Another option would be to take the primary key ID from a new row concatenate it to the string of the user's first and last name and then put it through and MD5 hash.

No matter which way you choose, the odds are astronamical of the same ID being generated twice.

For a specific GUID on one DB server is 1 in 36^32. For the MD5 hash to produce the same result a person with the SAME first and SAME last name would have to get the same primary key id (which can only happen if there are 2 or more DB servers) to get the same unique key.
codequestAuthor Commented:
Thanks for the message.  I appreciate the backup info on GUID's.  And I'll take another look at the MD5 Hash.

BTW, I thought that GUID's would be effectively unique no matter where they are generated, even if generated on several databases.   ?

And, actually, this is more of a problem about how to have smaller ID's (GUID's = 37 char, I'm looking for maybe 8-10 alphanum char) that are still unique, so that they can be used by external users externally.  

It's like when you sign up for a Hotmail or Yahoo email, and enter a ID, and they say "already taken".  Somewhere there's a master list of ID's that they check against, from all over the world.  

What I'm looking for is general patterns for how to accomplish that sort of thing on a smaller scale and with simple techonology.

Any thoughts on that?
codequestAuthor Commented:
I received additional helpful input on this here:


Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now