Proposal: locally unique GUID alternative

Question

The problem

I\'m looking for feedback on this exploration of a locally unique alternative for GUIDs, with the following requirement

Answer 1

At risk of being that guy that responds with "why would you want to do that?" -I am wondering what your underlying business problem is, that prevents you from using a GUID?

BIGINT, GUID, and HashTables..

I use a BIGINT for primary key which keeps everything sequential, unbloated and fast. This is for all internal work i.e. within my stored procedures, on SQL joins etc. Then I have a hash table with GUID's which becomes the starting point from external callers.

Since I use table inheritance, the BIGINT ID's can be used as a sequential primary key in my hash table as all ID's are unique across the entire database (yet still sequential). Then to take it further I create a composite key on the hash table that includes the last several digits of the GUID, and then I partition the hash table on those values so that each is stored separately on disk and still sequential, yet gives me a natural way to index on the GUID I'm looking up.

When I originally started doing it this way, I posted a how-to (excluding the partitioning part) here:

What is the fastest way to look for duplicate uniqueidentifier in Sql Server?

Initial performance tests were lightening fast against 100,000,000 records.

Not the answer to your question, but perhaps worth 2 cents to somebody.