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

> [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]
>
> > Тараканы у каждого - свои :)
>
> Причём тут тараканы? Повторю - это справочник!!!


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

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

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

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

И такая мысль имеется. Но, опять же дополнительный контрол должен быть для выбора типа искомого узла (город/область/район...), опять же с возможностью мультиселекта (город и деревня и улица). То есть нужен ещё один грид... громоздко получается...

Труп Васи Доброго ©   (23.01.09 11:27) [19]
Ты select * from table делаеш что ли? Если БД разрастется? Если обьемы будут не подьемные?

> что именно нужно юзеру, конкретная квартира или он город
> ищет?


Что именно нужно юзеру - он знает.
Вот и надо предоставлять ему возможность сужения области поиска, а не выдавать названия всех улиц в Галактике, начинающиеся с "Иван"

> Другие вполне могут делать по другому и работать у них будет
> по другому.

Подай мысль, как организовать данные типа "адрес" не в одной таблице и не иерархически? Учитывая, что количество уровней вложенности не ограничено, количество типов объектов не ограничено. Подчинённость объектов друг другу не ограничена и не однозначна (например может быть и город в районе и район в городе). Мне как то ничего другого не придумывается.
У меня на всё это три таблицы используется, для взаимосвязи и + одна таблица для каждого типа объектов для хранения специфических свойств.
Мне как то ничего другого не придумывается.

> [22] Jeer ©   (23.01.09 11:34)
> Что именно нужно юзеру - он знает.

Никогда не ограничевай юзера в его желаниях! Понятно, что нак писать легче, но ты пишешь не для себя, а для него. И если он захочет искать ВСЁ, что содержит в названии букву "А" он должен иметь эту возможность! И но должен получить правильный результат поиска в "красивом" виде.

Труп Васи Доброго ©   (23.01.09 11:43) [24]
Еще пользователь хочет получить данные быстро, поэтому используется форма в которой он выбирает что он хочет на данный момент, после этого формируется запрос в бд в котором ты сужаешь результирующий набор и подготовливаеш данные к отображению. Всякий раз закачивать всю БД в память и потом по ней в памяти делать поиск это черевато ошибками и тормазами.

Труп Васи Доброго ©   (23.01.09 11:39) [23]
Связанные таблицы не подойдут? Таблица справочник+оперативные.

> Всякий раз закачивать всю БД в память и потом по ней в памяти
> делать поиск это черевато ошибками и тормазами.

Сдаётся мне что ты не очень то в БД разбираешься....
Где я написал что загружаю, как ты выражаешься "БД в память"? Я вообще не понимаю что это значит.
У меня в гриде только подветки выбраной ветки, а Дерево это только отображает.

Глупости.
Если юзера не ограничивать то он будет шустрить в квэйк или лезть на порносайты, чтобы выяснить особенности Камасутры.

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

А странные желания пользователей пусть удовлетворяют странные же программисты.

Ниже иллюстративный пример, понятно, что в реальности возникают более сложные вещи.

Территориальные образования

Галактики
_Звезды
__Планеты
___Материки и о-ва
____Страны
_____Области ( штаты)
______Районы
_______Города ( поселки, села, деревни, аулы и пр )
________ Округа ( районы и пр. внутригородские объединения )

Адреса:
Улица и пр
_Дом ( строение)
__ Квартира ( офис )

> Связанные таблицы не подойдут? Таблица справочник+оперативные.

Ты читаешь, что пишут или просто так отвечаешь? Написано же:
> У меня на всё это три таблицы используется, для взаимосвязи