Функцията не е обратима, или поне не е при смислено избран хеш алгоритъм.
Пример - няма никакъв проблем ако записваш цели числа да ползваш като хеш индекс самото число. Но е напълно безмислено - хеш таблицата става толкова голяма колко самия сторидж в който ще държиш числата, и съответно търсенето там ще отнема толкова време колкото и в самия сторидж.
Също така няма никакъв проблем два различни записа да имат еднакъв хеш индекс. Все пак ако имаш 1 млн записа е добре функцията да връща някакво число в диапазона от 0 до поне 100 000, за да можеш да търсиш само между 10 записа. Но всичко това се определя въз основа на изискванията за обем и скорост.
Или друг пример - да се ползва ЕГН-то като индекс при търсене на запис за даден човек... да, като идея не е лошо, но ЕГН-то е от 10 цифри, тоест може да "поеме" 10 милиарда личности, а в БГ са само 7 милиона души... на практика е имате безмислен преразход на сторидж за самия хеш... Изобщо ЕГН-то не е подходящо за такива случаи - 3-та и 5-та цифра са ограничени откъм употреба и не се ползва целия потенциал на числото, няма равномерност. Ако ще се ползва нещо оттам, ще е по-добре да се вземат цифрите без 3-та и 5-та... така ще имате 8 числа (от 0 до 99 999 999), и ще имате горе-долу равномерност и по 70 човека на един хеш индекс. Ако вътре в данните с еднакъв хеш се ползва и сортиране, ще можете да намерите произволен човек само с 8 проверки - една за влизане в хеша и 7 за двоично търсене в 70-те записа с еднакъв хеш. Толкова "едър растер" на хеша позволява и да се гарантира че всички "джобове" на хеш таблицата ще бъдат горе-долу равномерно запълнени, а няма да се окаже че в една позиция имате 1 човек, а в друга - 20.
Ясно е че и поради тази причина функцията не е обратима - при правилно избрана хеш функция има по повече от един запис зад всеки хеш индекс, така че няма еднозначност при обратната операция.
