информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsГде водятся OGRыПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Дак в чем же дело? Используй рекурсию хранимых процедур. 24.07.08 16:35  Число просмотров: 2045
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
<programming>
Помогите побороть MS Jet SQL и деревья (иерархии). 24.07.08 08:04  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 24.07.08 11:00  Количество правок: 8
<"чистая" ссылка>
Есть таблица [Разделы]. В ней есть ключевое уникальное поле id и поле parent, которое содержит id своего родителя в этой же таблице. Или NULL, если это корень. Глубина иерархии, как вы поняли, получается неограниченная.
Задача 1) Найти все разделы, у которых есть общий предок. Ну то есть всех, кто ниже по иерархии от раздела с определённым ID. Если бы я это делал программно, путешествовал бы рекурсивно вглубь дерева, и собирал бы всех деток -))
Задача 2) Вроде как обратная первой задаче. Выяснить запросом, является ли раздел потомком заданного предка. Т.е. если бы я это делал программно, путешествовал бы в цикле верх по дереву, и проверял бы id заданного предка на равенство текущему -))

Правильно ли я понимаю, что средств чистого SQL для решения вышеуказанных задач недостаточно?

MDB база юзается внешним приложением через ADO. Я конечно могу делать для ADODB_Recordset->Seek() по ключевому полю, и всё сделать программно, но хотелось бы услышать ещё мнения.
Заранее всем огромное спасибо за советы!
Схожие (но другие) задачи я решал следующим образом: 25.07.08 05:13  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Схожие (но другие) задачи я решал следующим образом:
В таблице описания класса я хранил ссылку на родителя и дочку. Для быстрого выполнения запросов, типа найти всех предков за один раз - я делал вспомогательную таблицу "ReverseLookup" таблице, где храних пары ссылок:
ID ParentID
100;100
100;10
100;5
200;200
200;1
200;100

Надеюсь идея ясна. Например, можно было найти агрегированный список "методов" всех родителей. Таким обазом на обычной RDBMS (поверх) имплентирована OODB. Объектная ориетированность базы была понимаш! ;) С наследованием и полиморфизмом имплементированными.
Связанная таблица предполагает дополнительный слой логики при вставке/удалении элементов в дерево и перелопачивание того, что уже накодировано. Убедили, буду ручками парсить... -)) 25.07.08 08:12  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Да конечно - дополнительная таблица (избыточная по сути)... 25.07.08 15:26  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Да конечно - дополнительная таблица (избыточная по сути) требует дополнительной логикии на уровне аппликации по поддержанию "ссылочной целостности" (типа). Бенефит - скорость при запросах информации о свойствах родителей.
Дак в чем же дело? Используй рекурсию хранимых процедур. 24.07.08 16:35  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Нет хранимых процедур в базах *.mdb MS Access. 24.07.08 17:29  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Там есть только сохраняемые параметризованные запросы и таблицы.
Да, есть ещё т.н. модули, но мне проще тогда не на Access Бейсике в модуле, а прямо в аппликухе сделать всё что надо.

Хочется всё же на SQL -))
Сори, из корневого поста недопонял. 24.07.08 19:55  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
В таком случае, средств чистого SQL для решения вышеуказанных задач 100% недостаточно.

Можно, конечно, повыпендриваться с программным построением SQL запроса с вложенными селектами с кол-вом по максимально глубокому уровню, но ИМХО, это ваще порнуха!...
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach