Здравствуйте zvezda_t!,

в продолжении разговора про адреса:
zvezda_t
у меня есть кладр, но бывают случаи когда - хочешь - не хочешь приходиться адрес в ручную вбивать - ибо кладр не совершенен и некоторых адресов там нет.
вот поэтому я решила сделать отдельную таблицу для тех адресов которые не нашлись по кладр - или лучше оставить дополнительные адресные поля в каждой из таблиц?

Мы тогда решили, что лучше в одну таблицу адреса заводить.
Но я так понимаю вы все равно из самого кладра запросы строите.
Вам же не все адреса нужны, которые в кладре есть? Я так понимаю.
Т.е. Вам нужно хранить только нужные адреса в Вашей таблице, включая те, которые в кладре есть и те которых там нет.
И работать с ней, а не с кладром.
Кладр используется только во время ввода данных в таблицу адресов.
Например:
- триггер или просто процедурка на проверку правильности ввода адресов.
- представляет список улиц/областей и прочее на форме для ввода адреса.

А так если отвечать на Ваш вопрос, то два пути:
1) при перекачке KLADR в таблицы добавить дополнительные поля, по которым вы и будете строить запросы
2) если не хочется корректировать структуру (что странно, при закачке ведь все равно...), то можно посложнее сделать добавить доп. таблицы :
KLADR_EX
id
CODE - ссылка на кладр (по коду)
tip - тип, по которому будет отсеиватся записи, можно еще другие поля добавить

select * from dbo.kladr a inner join dbo.kladr_ex b on a.code = b.code where b.tip = ...

Т.е для каждой таблицы кладра будет соответсвующая "теневая "таблица в котором будут вычесленные поля.
На эти поля в любом из вариантов можно построить индекс.

zvezda_t
Да, я из самого КЛАДРа запросы строю

Ну не совсем правильно это...
Я живу в поселке, там 3 улицы.
Представляете, если в проге, где будут только люди из моего поселка, будут постоянно выполнятся запросы с кладром, где море адресов.
Это с проектной точки зрения неэффективно.
Если есть таблица адресов (своя) где хранятся адреса для людей в базе, то нет смысла лазить в кладр. Вед в той таблице будут поля: КодГорода, НаименованиеГорода и.т.д.
zvezda_t
потому что есть необходимость адреса менять
и тогда вновь открывается форма ввода адреса с использованием кладра, но эта форма грузиться очень долго, потому что адреса извлекаются по ранее сохранённому коду, идет полная расшифровка адреса, плюс подгружаются варианты выбора для каждого из адресов...
Ну может проблема тут еще в неэффективной работы с кладром на форме выбора адреса.
Тут примерно так:
Выбирается в списке область - получаем код.
Выбираем в списке город (отсеивается по области, т.е. показывем города только данной области) - получаем код.
Т.е. пошагово, не надо грузить все города и улицы в элементы управления.
Есть поле редактирования и справа некая кнопочка <...> по нажатию на которую выводится форма со списком. Во время нажатия на эту кнопочку происходить обращение к кладру.
Коды выбранных адресов, сохраняются и происходить сверка и прочие проверки с кладром.

При перекачке данных из кладра никто желательно не просто перекидывать таблички оттуда, а написать программу, которая постоит нужные дополнительные поля и индексы во врема алгоритма перекачки данных из кладра в Вашу базу... Тем более всякие "$region.$district.$city" вам явно не нужны, почему бы это не преобразовать при перекачке данных из кладра.

Простите если чего не так сказал и за много слов.

zvezda_t,

Вот еще мысли, может что понадобится, не знаю (видел готовое решение):

1. Таблица <Адреса> пример:
[id] = ...
[тип_адреса] = ...
[код_региона] = 50
[Район] = 'Клинский'
[город] = 'Высоковск'
[Населенный пункт]
[Улица]
[Дом]
[Корпус]
[Квартира]
[Код города] = '5001100200000'
[Код населенного пункта] = '5001100001000'
[Код района] = '5001100000000'
[Код улицы] = '55000000000124000'

2. Не нужно объединять районы + города, населенные пункты + улицы, а выбирать отдельно их.

3. Индексы строятся на кладровском поле CODE.

4. Запросы к кладру лучше, где это возможно, делать SELECT ... WHERE CODE = {Выражение} - тогда точно по индексу будет выбираться.

5. Главное правильно организовать форму ввода адреса.