JackRazz wrote:
Marcin,
| > I'm new to
| > hashtables and was hoping for the almost perfect hashtable that didn't require me
to
| > store the key, but I now see the impossiblity of what I wanted to do.
Well... what you describe is known as a cryptograhic hash: a
hash-function where it is virtually impossible to make two inputs which
maps to the same hashed value.
For example, when you digitally sign something, what you sign is not
really the entire document, but typically a cryptographic hash of it
(usually MD5 or SHA-1), but signing the hash is almost as good, since
noone will (hopefully) be able to come up with another text with the
same hashed value.
The key-space of IDictionary is only 2^32, which is (way) too small,
SHA-1 is 2^160, for relying on cryptographic hashing, but there may be
something else you can do.
If you can reject duplicate inserts, you can reject duplicate
hash-values instead. This effectively creates a partitioning of the
key-space, creating sets of equivalent keys.
While this would mean that you would be preventing certain sets of keys
from being in the database at the same time, it might be what you seek.
For example, if the keys are usernames or something similar, you could
say username already-taken... try another one.
BTW: If the keys are actually passwords, do not use the above solution,
2^32 is a small number in todays world :)
--
Helge