Связанная таблица предполагает дополнительный слой логики при вставке/удалении элементов в дерево и перелопачивание того, что уже накодировано. Убедили, буду ручками парсить... -))25.07.08 08:12 Число просмотров: 2371 Автор: HandleX <Александр М.> Статус: The Elderman
Есть таблица [Разделы]. В ней есть ключевое уникальное поле 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
Да конечно - дополнительная таблица (избыточная по сути) требует дополнительной логикии на уровне аппликации по поддержанию "ссылочной целостности" (типа). Бенефит - скорость при запросах информации о свойствах родителей.
Дак в чем же дело? Используй рекурсию хранимых процедур.24.07.08 16:35 Автор: Den <Денис Т.> Статус: The Elderman
Там есть только сохраняемые параметризованные запросы и таблицы.
Да, есть ещё т.н. модули, но мне проще тогда не на Access Бейсике в модуле, а прямо в аппликухе сделать всё что надо.
Хочется всё же на SQL -))
Сори, из корневого поста недопонял.24.07.08 19:55 Автор: Den <Денис Т.> Статус: The Elderman
В таком случае, средств чистого SQL для решения вышеуказанных задач 100% недостаточно.
Можно, конечно, повыпендриваться с программным построением SQL запроса с вложенными селектами с кол-вом по максимально глубокому уровню, но ИМХО, это ваще порнуха!...
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
