Здравствуйте 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. Главное правильно организовать форму ввода адреса.

zvezda_t
соответственно и выборка у меня смешанная. вот.
Вот пример работы формы:

Все делается последовательно.
При открытии формы с редактированием адреса к кладру обращения не происходит.
Т.к. в таблице адресов продублировано наименования реквизитов из кладра.
SQL запрос к кладру выполняется только тогда, когда пользователь нажимают кнопочку выбора значений.
Самое сложное - сделать проверку правильности ввода. Да и то сложность условная - нужно немного смекалки :)

Получаем:
- проблемы при открытии формы нет, т.к. к кладру прога в это время не обращается.
- проще запросы, т.к. нет всяких UNION и сложных WHERE.

zvezda_t
да... чувствую меня ждет глобальное изменение и вариант2 для ввода данных и новая организация таблиц)))
спасибо!
Мой совет:
Если у Вас есть время, лучше сделайте тестовый проект, и попробуйте разные варианты по вводу адреса. Тогда вам будет понятно как лучше-то сделать. И потом только принимайте решения.

Senya_L,
то что я писал - это не мое изобретение. Я в рабочем проекте видел это все.
Senya_LИ что, это большое преимущество? Если оператор влез в форму редактирования, то обращаться к БД все равно придется. Рано или поздно.
Ну как я понял, все началось вот с этого:
zvezda_t
тогда вновь открывается форма ввода адреса с использованием кладра, но эта форма грузиться очень долго , потому что адреса извлекаются по ранее сохранённому коду

Из этого я понял, что у нее все время при открытии формы каждый раз грузятся данные из КЛАДР.
Преимущество такое, что если оператору вдруг надо будет поменять всего лишь номер квартиры, то зачем лишнии загрузки, тормозящие работу программы?

Надо, к примеру, сменить улицу:
- оператор жмет кнопку
- выполняется запрос к КЛАДР с учетом предыдущих выбранных реквизитов
- появляется форма со списком улиц, к примеру, данного города
- оператор выбирает улицу, нажимает кнопку OK
- в таблице <АДРЕСА> прописываются значения в поля: <КОД УЛИЦЫ>, <НАИМЕНОВАНИЕ УЛИЦЫ>

И все по такому принципу. Нужен отчет выдать - имена атрибутов (район, улица,...) берутся из <АДРЕСА>, а не из кладр. Нужно поменять адрес - берем коды из таблицы <АДРЕСА> и выдаем форму со списком из кладр.

Вот я и решил, что все проблемы в организации работы формы.

Ну, это один из способов.