For a database I’m building, I’ve decided to use natural numbers as the primary key. I’m aware of the advantages that GUID’s allow, but looking at the data, the bulk of row’s data were GUID keys.
I want to generate XML records from the database data, and one problem with natural numbers is that I don’t want to expose my database key’s to the outside world, and allow users to guess “keys.” I believe GUID’s solve this problem.
So, I think the solution is to generate a sparse, unique iD derived from the natural ID (hopefully it would be 2-way), or just add an extra column in the database and store a guid (or some other multibyte id)
The derived value is nicer because there is no storage penalty, but it would be easier to reverse and guess compared to a GUID.
I’m (buy) curious as to what others on SO have done, and what insights they have.
What you can do to compute a “GUID” is to calculate a MD5 hash of the ID with some salt (table name for instance), load this into a GUID and set a few bits so that it is a valid version 3 (MD5) GUID.
This is almost 2-way since you can have a SQL computed column (which can also be indexed in certain cases) holding the GUID without persisting it in the table, and you can always re-compute a GUID with the correct ID and salt, which should be harder for users since they don’t know the salt nor the actual ID.