Быстродействие после Join

Question

Есть большой feature class улиц, таблица с уникальными номерами отрезков улиц и названиями улиц.
Если делаем Join, чтобы пользователь видел названия улиц - SDE работает очень медленно (5 секунд перерисовка - без Join 1сек).

Какая может быть причина в настройках SDE
или как можно показывать названия улиц по-другому. (Может в другом слое)?

Answer 1

Опять-таки от перекрёстка до перекрёстка. Т.е. улица может состоять, скажем, из 10 фрагментов.
А вдоль улицы, кстати, дома, у каждого дома - адрес. Каждому адресу приписана улица.
Сейчас это код из таблицы.
Внеся изменения один раз в таблице - исправляются и улицы и адреса домов.

Answer 2

Стандартными средствами, или можно на тему программных расширений фантазировать?

Answer 3

Программными понятно - какое-нибудь окошко с валидацией, автокомплитом или хотя бы фильтрацией по частичному совпадению.
Интереснее стандартными.
Я это всё к тому веду, что для исходной задачи (из первого поста) join всё ещё актуален, вьюшкой не всегда можно заменить. Как мне представляется.

Answer 4

TDenis

1. Так никто и не говорит, что join не актуален, просто помимо join`a "на лету", хотелось бы видеть нормальные вьюшки, а не "калек".

2. Если не секрет, а как Вы с помощью Join Вашу задачу решите стандартными средствами? Ну кроме как заставить пользователя выучить (смотреть) кода?

Answer 5

просто помимо join`a "на лету", хотелось бы видеть нормальные вьюшки, а не "калек"

Полностью с вами согласен!

2. Если не секрет, а как Вы с помощью Join Вашу задачу решите стандартными средствами? Ну кроме как заставить пользователя выучить (смотреть) кода?

Смотрят) Узнавали код по соседнему участку или адресу.
Обычно рисуют целиком одну улицу и все адреса - свой номер запоминают, постоянно смотреть не приходится)
    

Answer 6

А как потом Address Locator по такому слою строить ?? Для процесса создания слоя такой подход интересен (нету путаницы в названиях), но потом с таким слоем работать невозможно. Нужно заменять код названием улицы и потом работать только с этим слоем. Один слой (с кодами) - для редактирования, а второй (с названиями) - для отображения на карте. 

Answer 7

А как потом Address Locator по такому слою строить ??

Он не работает с присоединёнными полями?
Я правда не в курсе, у меня с ним пока как-то не сложилось - он меня не впечатлил. В 10-ке вроде есть какие-то изменения, надо будет попробовать снова что-нибудь построить.

Answer 8

PITKS
Ну, а адрессній локатор можно и по вьюшке построить...

Раз зашла такая тема, вопрос на засыпку:
А как заставить искать по составным названиям (Санкт-Петербург, Куала Лумпур, и прочее).. Если ввести первое слово, то находятся только одиночные названия?

Answer 9

Испытываю те же проблемы, что и TDenis.
Join и тормозит (таблицы по пол миллиона записей), и к тому же надо соединять таблицы каждый раз при создании проекта.
Хотелось бы сделать аналогично, только на стороне сервера, непосредственно средствами СУБД.
Кто-нибудь разбирался с мультиверсионными вьюшками?
И еще: создаю view через sdetable create_view, где класс улиц соездинен с таблицей названий. Все хорошо, только при изменении исходных данных, вьюшка не меняется.

Answer 10

И еще: создаю view через sdetable create_view, где класс улиц соездинен с таблицей названий. Все хорошо, только при изменении исходных данных, вьюшка не меняется.

Данные у Вас версионные. Изменения попадают в таблицы Axxx и Dxxx. В основной таблице изменения появятся, только после компрессии базы данных (если они согласованы). Вам придется учить что такое "мультиверсионные вьюшки" и как с ними работать.
В ArcGIS 10 появилась возможность создавать "слой запросов" - Query Layer.
Whats is Query Layer
Перед созданием "вьюшек" рекомендую потренироваться в работе с такими слоями - станут понятны возможности и ограничения.
Основное ограничение - запрос не должен "размножать" пространственные объекты. Т.е. при связывании Вы можете к каждому пространственному объекту добавить дополнительные атрибуты, а не ко множеству атрибутов добавлять по объекту.