Question

I have a situation where I need to create some kind of uniqueness between ‘entities’, but it is not a GUID, and it is not saved in a database (It is saved, however. Just not by a database).

The basic use of the key is a mere redundancy check. It does not have to be as scalable as a real ‘primary key’, but in the simplest terms I can think of , this is how it works.

[receiver] has List<possibilities>.

possibilities exist independently, but many will have the same values (impossible to predict. This is by design)

Frequently, the receivers list of possibilities will have to be emptied and then refilled (this is a business requirement).

The key is basically used to add a very lightweight redundancy check. In other words, sometimes the same possibility will be repeated, sometimes it should only appear once in the receiver’s list.

I basically want to use something very light and simple. A string is sufficient. I was just wanting to figure out a modest algorithm to accomplish this. I thought about using the GetHashCode() method, but I am not certain about how reliable that is. Can I get some thoughts?

Answer 1

If you can use GetHashCode() at a first glance, you can probably use an MD5 hash as well, obtaining less collision probability. The resulting MD5 can be stored as a 24 charachter string by encoding it base 64, let see this example:

    public static class MD5Gen
    {
        static MD5 hash = MD5.Create();
        public static string Encode(string toEncode)
        { 
            return Convert.ToBase64String(
            hash.ComputeHash(Encoding.UTF8.GetBytes(toEncode)));
        }
    }

with this you encode a source string in an md5 hash in string format too. You just have to write the “possibility” class in term of string.