Привет всем! Нужна идея/мысль/намёк как производить поиск по таблице, содержащей иерархические данные?
Я что то впал в ступор. Сама таблица есть, отображение через Тривью есть, теперь вот встала проблема поиска...
Как бы "ппоправильнее" его сделать? Данные - по сути похожи на адрес (пусть будет база почтовых адресов для определённости).
Сама загвоздка вот в чём: Допустим я ищу "Иванов*", если бы в базе была только одна такая запись, то проблем нет - раскрыл ветку, содержащую это слово до нужного уровня и всё. А вот как "правильнее" показать на дереве результат поиска, если таких слов несколько, да ещё некоторые содержат ветки с таким же словом? Например как "правильнее" показать "Ивановская область" - "Мухосранский район" - "г. Задрищенск" - "ул.Иванова"???
Открыть две ветки - глупо, она же по сути одна. Просто открыть ветку до "ул. Иванова", как бы неявно теряется результат "Ивановская область"
И как вообще организовать сам поиск???

> [0] Труп Васи Доброго ©   (23.01.09 09:16)
> "Ивановская область" - "Мухосранский район" - "г. Задрищенск" - "ул.Иванова"???
Дуэль. Только дуэль. Такое смывается только кровью. Так обгадить мою малую Родину!!!
8-)

> Открыть две ветки - глупо, она же по сути одна
А зачем показывать результаты поиска прямо в дереве? Можно ведь и в отдельном окошке с раскрученой в строку иерархией, похожей на ту, которой ты меня обидел. И пусть юзер выберет нужное.

> Сама загвоздка вот в чём: Допустим я ищу "Иванов*",
..
Открыть две ветки - глупо, она же по сути одна


Нет загвоздки - компьютер ничего не знает о понятии "глупость" и не будет за тебя домысливать, что существуют еще категории "ФИО" и "Область" и тп


> как производить поиск по таблице, содержащей иерархические
> данные?


Поиск можно производить как по Dataset-у, так и по TreeView.
Что и почему удобнее - решать тебе на месте.

Если у тебя на мильен записей найдется сто тыщ "*Иван*" - что бум делать ?

Да как то не красиво, не хотелось бы нагружать приложение (кое по сути будет справочником для выбора "адреса") лишними окнами.
Есть дерево, сбоку ДБГрид с содержимым выбранного узла, добавление удаление узлов есть, всё логично и красиво. Но нужен поиск! Вот и прошу идею как лучше сделать. Сначала хотел сделать как поиск в реестре и выдавать результат по очереди (типа "далее") но это криво. Юзер может не знать что конкретно он ищет и пока от доnextскается до последнего результата - забудет что было в начале, придётся опять искать. Так что такой поиск отпадает. Надо сразу все "результаты на лицо", а там пусть выбирает что ему надо, улица или область.
З.Ы. Про малую родину не обижайся, я вообще в Урюпинске живу, а его в каждой дыре обкакивают :)

> Если у тебя на мильен записей найдется сто тыщ "*Иван*"
> - что бум делать ?

Так вот это я и пытаюсь придумать! Что посоветуешь?

А у меня при нажатии на кнопку "Отфильтровать" подменяется запрос с подстановкой фильтра типа такого:


А на форме написано: "Внимание! При действующем не пустом фильтре дерево
подразделений отображается некорректно т.к. там отсутствуют
подразделения, которые не попали в фильтр."

> [3] Труп Васи Доброго ©   (23.01.09 09:46)
> нагружать приложение (кое по сути будет справочником для
> выбора "адреса") лишними окнами

Дык отдельное окно - это по вкусу. Можно и просто грид какой-нибудь на выезжающей панели например. Т.е. проблема скорее дизайнерская.

А у меня при нажатии на кнопку "Отфильтровать" подменяется запрос с подстановкой фильтра типа такого:


А на форме написано: "Внимание! При действующем не пустом фильтре дерево
подразделений отображается некорректно т.к. там отсутствуют
подразделения, которые не попали в фильтр."

> Поиск можно производить как по Dataset-у, так и по TreeView.

По дереву искать нельзя, я не заполняю его сразу (нафига это нужно), а по мере раскрытия ветвей.

> Труп Васи Доброго ©   (23.01.09 09:56) [8]


При "мильёне" потенциально существующих в НД Ивановых неразумно показывать их всех одновременно в деревянном контроле.

Разумней вывести их всех (точнее - пути к каждому из них и по необходимости иные атрибуты) в отдельный скроллируемый табличный контрол.

Юзер выбирает строку в этом табличном контроле, а ты создаешь и открываешь-показываешь в деревянном контроле маршрут к соответствующему Иванову.

> Труп Васи Доброго ©   (23.01.09 09:56) [8]
>
> > Поиск можно производить как по Dataset-у, так и по TreeView.
>
>
> По дереву искать нельзя, я не заполняю его сразу (нафига
> это нужно),


Тараканы у каждого - свои :)

Насчет отображения:
Я отношу иерархии к справочным материалам и содержание их должно быть максимально лаконичным.
Отображение иерархии делал в строку с разделителем, например в твоем случае:
Ивановская область\Мухосранский район\г. Задрищенск\ул.Иванова
Ивановская область\Сладкий район\г. Передрищенск\ул.Иванова-Петрова

Но для этого надо иметь весь тривью и подниматься вверх по иерархии - либо городить на сервере процедуры.

Я аналогичную проблему решил следующим образом:
Поиск идет в базе (только среди "листьев")
Есть ограничение на максимальное число результатов поиска (управляется самим пользователем)

Результатом отбора является список найденых элементов.
Дерево раскрывается (при необходимости достраиваясь) до первого из найденых.
При необходимости пользователь "гуляет" по списку найденых (визуально находится под деревом) при этом достраиваются и раскрываются нужные ветки.

P/S Мне кажется вопрос сформулирован абсолютно неправильно. Что нужно автору я понял (может быть неправильно) только из обсуждения

> Тараканы у каждого - свои :)

Причём тут тараканы? Повторю - это справочник!!! Основное его назначение это выбор "адреса" для объекта в другой таблице. Вот и представь себе, что оперетор сидит, вводит данные, добрался до адреса, тычет кнопку "справочник" а он не мгновенно открывается, как сейчас, а подвисает, пока построится полностью всё дерево из сотен тысяч узлов, и всё для того, чтобы ткнуть один и закрыть справочник. Для следующей записи ситуация повторится.
ИМХО это не есть разумно.
Я так понимаю все склоняются к мысли что надо делать дополнительный грид с результатами. (Идея с выезжающей боковой панелью мне понравилась, стырю!)
В принципе это и мне вначале пришло в голову, но решил спросить мнения уважаемых людей.

Я такое зделал хранимой процедурой, если одно поле в результирующем наборе то через while, если нет то можно по связи таблицы с собой.

select a.name,b.name,c.name,d.name from
tablename a
join tablename b on
a.pred_id = b.id
join tablename с on
b.pred_id = c.id
join tablename в on
c.pred_id = d.id
where a.id = 3

или

select a.name+" "+b.name+" "+c.name+" "+d.name from
tablename a
join tablename b on
a.pred_id = b.id
join tablename с on
b.pred_id = c.id
join tablename в on
c.pred_id = d.id
where a.id = 3

Подходит только если количество уровней известно заранее.

test   (23.01.09 10:59) [13]
Если вложенность не имеет конкретных границ, то тогда через создания курсора и while.

> Если вложенность не имеет конкретных границ, то тогда через
> создания курсора и while.

Вложенность, как и тип объекта не имеют ограничений, поэтому для вывода "полного адреса" используется рекурсия в ХП
З.Ы. Я как бы не про то спрашивал.

а что, нельзя заренее указать, что он ищет именно район, а не улицу/деревню/забор?
т.е. категорию поиска сузить, а не просто название шарить

Труп Васи Доброго ©   (23.01.09 11:13) [15]
Почему бы сразу не получить данные из БД в нормальном виде?

> Труп Васи Доброго ©   (23.01.09 10:52) [12]
>
> > Тараканы у каждого - свои :)
>
> Причём тут тараканы? Повторю - это справочник!!!


Еще раз - тараканы у каждого, свои.
Это ты так решил залить все в одну таблицу и получить мильены адресов, да еще и иерархически их строить.
Другие вполне могут делать по другому и работать у них будет по другому.
Может даже эффективнее.

> Почему бы сразу не получить данные из БД в нормальном виде?

Для начала поясни что значит "нормальный вид"? В каком виде должены быть получены данные справочника адресов, учитывая, что ты изначально не знаешь, что именно нужно юзеру, конкретная квартира или он город ищет?