Мало того, что ОКВЭД/ОКОНХ и ОКПО могут совпадать, и они и ИНН могут быть неизвестны в момент ввода. Для филиалов ИНН может совпадать (отличаются по КПП). И все эти параметры могут менятся.
И кстати, непонятно, какое отношение имеет напр. ИНН или классификатор внешнеэконм. деятельности к адресу?

И напоследок, нафига такой "разобранный" (отдельно дом, улица и пр.) адрес?
Nobody faults but mine... (LZ)

У меня есть в чем-то схожая проблема. А именно, есть клиентская база.
Клиенты м.б. как юрлица, так и физлица, а также ПБОЮЛ и кредитные ор-ции. Во всех случаях наборы реквизитов отличаются.
Ключ - разумеется, суррогатный, напр. objectID
Проблема заключается в определении уникальности клиента. Во-первых, для разных типов клиентов она определяется по-разному. Например, у ф/л ИНН как правило нет (точнее, они его не знают). Во-вторых в момент ввода в базу часть ревизитов - даже обязательных, таких как ИНН для юрлица, может быть неизвестна. В-третьих, ревизиты иногда меняются. В силу чего есть сложная процедра определения уникальности по сочетании реквизитов. К сожалению, гарантировать уникальность в принципе невозможно, можно только снизить возможность появления дублирующихся клиентов.

NICKNAME тоже есть, как обязательное и уникальное поле, но он уникальность обеспечить не может. NICKNAME - это только NICKNАME и есть, удобство поиска, и ничего больше. Взяли и сделали два "ОАО НПП Жиртрест-98 тыры-пыры... " под разными никами. И трындец.



Nobody faults but mine... (LZ)

NICKNAME можно сделать уникальным ключем - но, поскольку он вводится руками, он не может обеспечить уникальность клиентов. Т.е., как уже обьяснял, можно ввести два раза одного и того же клиента под разными nickname.

Nobody faults but mine... (LZ)