информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыSpanning Tree Protocol: недокументированное применениеПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Очередное исследование 19 миллиардов... 
 Оптимизация ввода-вывода как инструмент... 
 Зловреды выбирают Lisp и Delphi 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
если вы видите этот текст, отключите в настройках форума использование JavaScript
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
Связанная таблица предполагает дополнительный слой логики при вставке/удалении элементов в дерево и перелопачивание того, что уже накодировано. Убедили, буду ручками парсить... -)) 25.07.08 08:12  Число просмотров: 2366
Автор: HandleX <Александр М.> Статус: 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 <Денис Т.> Статус: The Elderman
<"чистая" ссылка>
Нет хранимых процедур в базах *.mdb MS Access. 24.07.08 17:29  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Там есть только сохраняемые параметризованные запросы и таблицы.
Да, есть ещё т.н. модули, но мне проще тогда не на Access Бейсике в модуле, а прямо в аппликухе сделать всё что надо.

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

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




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


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