[Borland]

Нужно учитывать ещё одну тонкость: наличие дополнительного пробела в адресе или различие в регистре одной буквы или тому подобная ерунда изменит хэш до полной неузнаваемости...
Можно, конечно, прикрутить к процедуре ввода справочник типа КЛАДР и хранить адреса в стандартизованном виде, выверенном по справочнику; а для сравнения адресов использовать хэш CRC32 (впрочем, возможно будет достаточно и CRC16). Но здесь нужно учитывать, что лишний справочник + процедура приведения адреса к стандартному виду тоже требует времени на обработку, да и процедура вычисления хэша для вновь вводимого адреса "небесплатна" (в смысле вычислительных ресурсов)...
А кроме чисто вычислительных ресурсов, неплохо бы учесть и траффик. Это некритично, если база локальная, а вот работа с КЛАДР через Интернет создаст весьма нехилую нагрузку на канал (и на веб-сервер).

В общем, хэшированиение нестандартизованных адресов ИМХО бессмысленно. А их предварительная стандартизация при вводе увеличит ресурсоёмкость приложения (и его сложность) на порядок...

P.S. Прикрутив к процедуре ввода КЛАДР, можно хранить в базе не название улицы и города с почтовым индексом, а цифровой код соответствующего элемента КЛАДР (и его-то и использовать "вместо хэша") - но, повторюсь, только если база локальная либо у клиентской части базы свой локальный КЛАДР (ага, и локальная СУБД, в которой он крутится; и не нужно забывать о том, что КЛАДР воизбежание разночтений необходимо обновлять на сервере и на клиенте одновременно).
В общем, сдаётся мне, овчинка не стоит выделки...