Скачать: CL | DM;

Рекурсивная выборка в Ассess   Найти похожие ветки 

← →
AccessBeginer   (2002-11-30 16:45) [0]

Нужен сабж, но с помощью одной sql комманды...

Более побробно:

CREATE TABLE Box(
Id integer,
IdParent integer,
Remark VARCHAR(20)
);

ALTER TABLE Box
ADD PRIMARY KEY (ID);

ALTER TABLE Box
ADD FOREIGN KEY (IdParent)
REFERENCES Box
;

Те IdParent ссылается на вышестоящий ящик. Обычная иерархичная структура, загнанная в реляционную табличку.

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

На том же IB это делается елементарно с помощью хранимой процедуры.

Можно ли получить эту рекурсивную выборку с таблицы аксеса с помощью ОДНОЙ sql комманды (или чего-то подобного, которое с клиенской программы можно дернуть с помощью ОДНОГО запроса)?

Сорри за немного странное желание. Вариант решения типа "пошли ты этот аксесс и возьми нормальную платформу", к сожалению не проходт....

---

← →
BlackTiger   (2002-11-30 19:04) [1]

Эк вы, товарсч, загнули...
Насколько я понял - вложенность неограничена?

Боюсь, что простым запросом не получится. Тут нужно решать на уровне данных, а не запросов. Рекурсия, сама по себе, дело неблагодарное. По опыту знаю, что в 99.99% случаев ее можно избежать и преобразовать к "человеческому" виду.
Нужно делать так, чтобы потомок ссылался на родителей, на родителей родителей и тыды. Можно сделать так:

| Номер бокса | Код вложенности |
1 "{1}"
2 "{2}"
3 "{3}"
4 "{1}{1}"
5 "{1}{2}"
5 "{3}{3}"
6 "{1}{3}"
7 "{2}{1}"
8 "{2}{2}"
9 "{2}{2}{1}"
9 "{1}{2}{1}"

и так далее. В результате сделав запрос
"SELECT ... WHERE [Код вложенности] LIKE "{1}*""
Ты получишь

| Номер бокса | Код вложенности |
1 "{1}"
4 "{1}{1}"
5 "{1}{2}"
6 "{1}{3}"
9 "{1}{2}{1}"

Это тебе надо было?

---

← →
BlackTiger   (2002-11-30 19:13) [2]

Сейчас смотрю - чуствую, что где-то что-то не в порядке, но сама идея такая. Необходимо наличие отдельного "кода вложенности", куда заносится описание вхождений одной коробки в другую с сохранением вложенности "вышестоящего" бокса.

Блин, сам загнул так, что сейчас мозги закоротит.

---

← →
AccessBeginer   (2002-11-30 20:14) [3]

Дык проблемс в том, что обход может начаться с любого уровня вложенности и уровень вложенности может быть любой. То есть кол-во ссылок может быть разным. А держать в одном поле строковый эквмвалент набора ссылок - ну и извращенец вы, батенька. Наплевательски относится к неодному канону нормализации реляционных баз .... Не говоря о необычайно лизкой производительности выборки по LIKE ....
Также несколько бредовато развитие Вашей идеи - сделать еще одну табличку, где два поля - собстенно номер текущего бокса в паре с любым вышестоящим, и там пересчивать все вышестоящие... Ну как бы связь типа много к многим, но сам на себя :-)....
Там хоть запросы быстро выполнятся будут ....

---

← →
sniknik ©   (2002-11-30 22:09) [4]

Вопросы повторяются с завидной регулярностью :о)).

смотри что здесь уже было, и главное ответ, по моему самое то, во всяком случае идея.

Записи в таблице представляют собой дерево (поле PARENT_ID ссылается на поле ID - т.е. на запись-предок).

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

select P1.*,P2.ID,P3.ID ...
(select Parent_ID from TABLE where ID=<тот самый ID>) P1
left join TABLE p2 on p1.Parent_ID=p2.ID
left join TABLE p3 on p2.Parent_ID=p3.ID

---

← →
BlackTiger   (2002-12-01 15:09) [5]

"Наплевательски относится к неодному канону нормализации реляционных баз"

Не согласен! Какая постановка задачи - такой и ответ!
Да и рекурсия данных - не извращение? Я просто предложил идею, и ни в коем случае не говорю, что она правильная. Это было ПЕРВОЕ, что пришло в голову при наличии таких входных данных.

Что нужно видеть? "Из чего состоит бокс" или "В каких боксах участвует данный бокс". Две большие разницы, однако.

Про "нормализацию" - почему все доходят до стадии "нормализация", но напрочь забывают, что следующим этапом идет ДЕНОРМАЛИЗАЦИЯ данных?

Ко всему прочему, боюсь, что Аксесс тебе тут ничем не поможет. Реализуй дельфийским кодом.

---

← →
AccessBeginer   (2002-12-01 18:39) [6]

2 sniknik © (30.11.02 22:09)

Вопросы может и повторяются, но не ответы ...
Вариант, предложенный/процитированный Вами, не проходит по двум причинам:
- обработка только три уровня вложености (я конечно понимаю, что можно налепить столько джойнов, сколько макс. уровней вложености, НО я говорил, что уровень вложенности может быть произвольный ... (см 30.11.02 20:14 )
- результат должен быть как набор записей, а не как одна запись с кол. полей, которое равно макс. уровнювложенности.

Но все равно спасибо за внимание.


sniknik © (30.11.02 22:09)


> Да и рекурсия данных - не извращение?



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


> Какая постановка задачи - такой и ответ!


Ну Вы мастер передергивания... Нормальная постановка задачи и вопроса (даже с описанием структуры табличек :-)...


> при наличии таких входных данных.


Предложите свою (иную) модель иерархической структуры в реляционной базе (надеюсь, Вы осознали, что Ваше высказывание по поводу "рекурсии данных" © sniknik несколько это самое, опрометчиво...



>
> Про "нормализацию" - почему все доходят до стадии "нормализация",
> но напрочь забывают, что следующим этапом идет ДЕНОРМАЛИЗАЦИЯ
> данных?


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



> Ко всему прочему, боюсь, что Аксесс тебе тут ничем не поможет.

Ну, это пожалуй единое бесспорное утверждение из Вашего постинга...
Для себя я сделал вывод, что я последний раз соглашусь иметь дело с аксесом в проектах, где будет больше, чем несколько табличек, и связи несколько более интелектуальные чем вида список покупателей к списку накладных .... :-(

---

← →
BlackTiger   (2002-12-01 20:25) [7]

Интересно, как ты представляешь алгоритм ОТОБРАЖЕНИЯ дерева с неизвестным уровнем вложенности? Только через обсчет КАЖДОГО УЗЛА отдельно. Задача -
1. "в каких каталогах находится файл ABC.TXT на всех дисках системы".
2. Решить ОДНИМ перебором за ОДИН проход.

Ну! Ваши варианты? Быстрый алгоритм только такой - иметь таблицу расположения файлов вида
<имя файла><полный путь папки>

И никакой рекурсии! Избыточность - да, но не рекурсия. Рекурсия - главным враг всех программистов! Родственник твоей задачи - отображение расчет т.н. BOM-а (bill of materials, по-русски - рецепт приготовления/производства), который, в свою очередь тоже состоит из BOM-а. Его решение только во временной таблице и ее заполнении.

Еще! Не бывает НЕОГРАНИЧЕННЫХ рекурсий. У любой рекурсии есть "условие выхода из рекурсии". Далеко не всегда этим является нулевой результат текущего этапа.

И нечего наезжать на Access! Он тут ни при чем, абсолютно. Просто в нем не хватает необходимой функциональности, но это решается внешним кодом.

Пересмотри структуру и перейди от "объемной модели" к "плоской".

---

← →
Ihor Osov'yak ©   (2002-12-02 15:21) [8]

Первым делом сорри за пред. анонимность, есть комплекс стыда задавать несколько глупые вопросы в тех областях, где опыта маловато ( спич об том же аксесс). Но поскольку далее несколько резковатый комментарий пред постинга. то я "авторизуюсь".
Еще раз сорри.

2 BlackTiger (01.12.02 20:25)

Я ни слова не говорил об " ОТОБРАЖЕНИИ". Это к слову. Имелось ввиду рекурсивный обход иерархической структуры. Модель данных для которой был приведен в самом первом постинге.

Если Вам непонятно о чем речь - простой аналог - команда dir с ключом /s для файловой системы.

Еще - Слово произвольный и слово неизвестный имеют несколько разные значения. Но даже одображения древовидной структуры с неизвестным на определенной стадии обработки уровнем вложенности не предстваляет особой проблемы - вспоминаем тот же TTreeView (конечно, тут неизвестен "уровень вложенности" только на определленом этапе - при обработке промежуточных уровней; при достижении терминального уровня, мы об этом узнаем)

> Еще! Не бывает НЕОГРАНИЧЕННЫХ рекурсий. У любой рекурсии
> есть "условие выхода из рекурсии". Далеко не всегда этим
> является нулевой результат текущего этапа.


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

1. "в каких каталогах находится файл ABC.TXT на всех дисках системы".
2. Решить ОДНИМ перебором за ОДИН проход.

> Ну! Ваши варианты? Быстрый алгоритм только такой - иметь таблицу расположения файлов вида
<имя файла><полный путь папки>

Совсем уходод темы. Ибо у меня каждий элемент имеет уникальный ID (а имя файла далеко не уникально, имеется ввиду не полный путь для имяни файла ) - см. описание структуры, он собственно и служит для быстрой выборки. Связка
ALTER TABLE Box
ADD FOREIGN KEY (IdParent)
REFERENCES Box
;
предназначена не для быстрой выборки, а имено для отображения взаимосвязи главный/вышестоящий к подчиненному/вложенному...

Пересмотри структуру и перейди от "объемной модели" к "плоской".


Ну батенька... Но коментс... Что вы понимаете под "плоский", "обьемный" и в каком контексте? Реляционная табличка то плоская, но моделирует иерархическую сущность реального мира, которая уж никак плоской не станет, при всем вашем желании.

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

Зы2 А прызывы к избыточности ... Вы тут также не правы. Особенно если вспомнить об достоверности и непротиворичивости ...

Зы3

> Рекурсия - главным враг всех программистов!


Ну, блин, некоторым танцорам, знаете что мешает?

Но впрочем, всеравно спасибо за диалог (невзирая на то, что имхо Вы немного не о том спич несли ...)

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.5 MB
Время: 0.011 c