How do I calculate a good hash code for a list of strings?

Background:

  • I have a short list of strings.
  • The number of strings is not always the same, but are nearly always of the order of a “handful”
  • In our database will store these strings in a 2nd normalised table
  • These strings are never changed once they are written to the database.

We wish to be able to match on these strings quickly in a query without the performance hit of doing lots of joins.

So I am thinking of storing a hash code of all these strings in the main table and including it in our index, so the joins are only processed by the database when the hash code matches.

So how do I get a good hashcode? I could:

  • Xor the hash codes of all the string together
  • Xor with multiply the result after each string (say by 31)
  • Cat all the string together then get the hashcode
  • Some other way

So what do people think?


In the end I just concatenate the strings and compute the hashcode for the concatenation, as it is simple and worked well enough.

(If you care we are using .NET and SqlServer)


Bug!, Bug!

Quoting from Guidelines and rules for GetHashCode by Eric Lippert

The documentation for System.String.GetHashCode notes specifically that two identical strings can have different hash codes in different versions of the CLR, and in fact they do. Don't store string hashes in databases and expect them to be the same forever, because they won't be.

So String.GetHashcode() should not be used for this.


Standard java practise, is to simply write

final int prime = 31;
int result = 1;
for( String s : strings )
{
    result = result * prime + s.hashCode();
}
// result is the hashcode.

I see no reason not to concatenate the strings and compute the hashcode for the concatenation.

As an analogy, say that I wanted to compute a MD5 checksum for a memory block, I wouldn't split the block up into smaller pieces and compute individual MD5 checksums for them and then combine them with some ad hoc method.


Your first option has the only inconvenience of (String1, String2) producing the same hashcode of (String2, String1). If that's not a problem (eg. because you have a fix order) it's fine.

"Cat all the string together then get the hashcode" seems the more natural and secure to me.

Update: As a comment points out, this has the drawback that the list ("x", "yz") and ("xy","z") would give the same hash. To avoid this, you could join the strings with a string delimiter that cannot appear inside the strings.

If the strings are big, you might prefer to hash each one, cat the hashcodes and rehash the result. More CPU, less memory.