I was reading some questions here and a question came up on one of those questions .
If I have an application I need to store strings in a database to compare later with something, but I do not need the texts, just need to know if they are the same, would not it be better for me to store the hash code which is short in place of the text? From what I read, correct me if I'm wrong, that switch uses hash code to select strings so I wanted to do the same thing.
You can not. The hash code is not stable, it may use different formulas depending on the version used. Furthermore, even within the same application run, there may be a different algorithm if you have more than one AppDomain since each one can run a different version of the CLR or even the code of your application. Even if you do not use AppDomain , you still have a problem.
It is still possible to have two different strings with the same hash code , so you can not trust it. The switch uses the hash code mechanism only to improve the selection performance, but then it confirms that it is the same with the string , which is fine best to buy all strings . To do the same with the database would have to store the string anyway. As it is a database performance gain will be negligible, not worth the effort.
If you want to have collisions, that is, if your case does not matter, it would be ideal to create a hash code system to avoid relying on the .NET implementation or other < a CLR that can use a very different algorithm than any other version of .NET since there is no specification of the exact algorithm. At least in this way it could guarantee the stability of the algorithm.
You could store the first few characters of the string next to the hash code , so it's very unlikely but not guaranteed that it has a code collision with equal start. This way there is still a risk, but it is very low, "almost" the same as using a GUID . p>
