>>Strictly speaking, I don't really need GUID, just as Sergey Berezniker has pointed out what a GUID key should be. In my case, I just need a non-sequential char type surrogated key, so I think I am cutting down the length, probably 8 to 12 chars since there are tables that I expect will grow huge in term of #records.
>
>8 or 12 will not save enough to be any advantage. Go either integer or 16 byte GUID. Why stress yourself over this? The integer data type and the GUID datatype are very well understood. Coming up with some custom 8 / 12 byte "unique" key is a waste of time.

I'd concur here. It's not exactly a waste of time, i.e. not entirely fruitless, it's just a matter of economics. A 12 byte key wouldn't gain much in time and resources to outweigh the cost of development. The 16 byte GUID can be easily derived from an API call (I saw how VFE does it - and so can probably other frameworks, and there may be code elsewhere too), which IMO means that instead of doing a whole day or more of research, we can take ten minutes to implement one of the existing solutions.