Using Hashes as Unique ID

I am creating a database that will hold a number of transaction records.

I was wondering if it is a good idea or good practice to use a hash function that can be replicated easily for verification as the ID column. i.e. SHA1(UserID + TimeOfTransaction)

Generally not a good idea, for the following reasons:

• If someone knows UserID and times, they may be able to match that back to transactions (depending on how this ID is exposed - if it's exposed externally via an API, someone knowing UserID could generate candidate TransactionIDs from guessed times)

• High amount of entropy in the key means that your indexes on this key are going to fragment rapidly. If your DB has a page cache, the cache efficiency will drop as your data volume grows (this can be a killer).

• If you can handle the performance concerns, then why not just generate a GUID?

StackExchange Database Administrators Q#144501, answer score: 3