информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеГде водятся OGRыАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Дак в чем же дело? Используй рекурсию хранимых процедур. 24.07.08 16:35  Число просмотров: 2307
Автор: 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-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach