Хеш-код как поле для сравнения?
 

Вопрос такой: есть база данных и в ней таблица "адрес", мне нужно добавляя нового клиента проверять не существует ли уже добавляемый адрес клиента в таблице(2 клиента из однои семьи и тд.), я решил, что (чем сравнивать каждый раз несколько полей), можно объединять улицу + номер дома + индекс + город в одно длинное слово снимать хеш (метод в Java: String.hashCode() ) и хранить его в таблице "адрес", чтобы воспользоваться этим полем для сравнения при добавлении клиента и вот хотелось бы узнать намного ли я выиграю в скорости сравнивая по хеш, а не по полям (улица,номер дома,индекс и тд.)?

П.С. База данных PostgreSql 8.3, язык Java.

Настолько насколько хэш короче самой строки.

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

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

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

М-да... действительно. Просто мне казалось, что базе данных искать цифры легче, чем буквы с цифрами. А насчет пробелов... они бы просто удалялись из слова, и как я говорил, получалось бы одно длинное слово. Ну вобщем ясно. В любом случае спасибо за оперативное разъяснение.