On 8/7/07, Boyd Hemphill <[EMAIL PROTECTED]> wrote: > > Suggestions to use a hash are a problem because once you have a few > million rows the likelihood of a collision is quite high if you cannot > afford an error stopping your application. This means that if you write a > trigger (the obvious way to go) you will need to trap any uniqueness > violation and try again with different salt.
Also, I think in the original post you cited "security". I'd be curious to know what you are protecting against. Using web browser session identifiers as an example, the most common approach is to have a fixed part of the session identifier concatenated with a cryptographic hash. Typically, the hash is formed based on the index of the database row concatenated with some secret state known only to the server, i.e. something like SHA1(secret_state + row_index + secret_state) That elminates an attacker's ability to forge a session identifier, because they can't map from the row index to the hash without possessing the secret state. If your application is similar, uniqueness of the hashes may be a non-issue. It is true that a hash collision _could_ occur, but it would be of no consequence because the possibility of collision doesn't help an attacker. So, it wasn't clear where your uniqueness requirement came from or if the hash really needed to be part of a database key. Dave
