Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
Сори, из корневого поста недопонял. 24.07.08 19:55 Число просмотров: 2163
Автор: Den <Denis> Статус: The Elderman
|
В таком случае, средств чистого SQL для решения вышеуказанных задач 100% недостаточно.
Можно, конечно, повыпендриваться с программным построением SQL запроса с вложенными селектами с кол-вом по максимально глубокому уровню, но ИМХО, это ваще порнуха!...
|
|
<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 запроса с вложенными селектами с кол-вом по максимально глубокому уровню, но ИМХО, это ваще порнуха!...
|
|
|
подробно о проекте
Анализ криптографических сетевых...
