Проблема с построением дерева по структуре из mdb

[Алексей К.]

имею структуру дерева в access:
(код,key,parent_key,text)
ключ вида "123key", т.е. цифра + "key".
Изначально структуру беру с винчестера и записываю ее в базу, тем самым при сортировке по полю "код" имею правильный порядок узлов и дерево строится без проблем. В клиенте есть фича по перемещению узлов, так вот при повторном запуске в процессе построения дерева порядок следования узлов становиться не правильным (например сначала идет запись дочернего узла, а за ней запись узла - родителя) и в момент создания дочернего узла его родительский узел еще не создан - соответственно ошибка "Элемент не найден (родитель)". Как правильно упорядочить набор записей в отношении потомок-родитель? Естественно одним запросом здесь не обойтись, может кто уже занимался упорядочиванем структуры дерева?

[alibek]

Добавь еще одно поле, Level. Сортируй по нему. Тогда описанной проблемы не будет.

[Алексей К.]

Спасибо , по пробую.

[Antonariy]

Рекомендую изменить структуру таблицы в соответствии с принципом вложенных множеств. Если требуется активная работа с ветками, то такая структура удобнее.
http://www.webscript.ru/stories/04/09/01/8197045

[alibek]

Antonariy, в целом да.
Но для простых случаев удобнее использовать простые решения (типа поля level или fullpath).

[Alexanbar]

Создать запрос с новым полем типа "полный путь" и отсортировать по нему

[HandKot]

если данных не много, то можно применить и такой вариант

1 заход - заполняем дерево у узлов не указываем родителя
2 заход - проставляем парентов

[RayShade]

HandKot

Это прокатит, возможно только в VBNET. Стандартный treeview6, такого не умеет.

[Antonariy]

Сортировку в баню, разве что оставить в пределах узла.

Код: Выделить всё

Sub FillTree(rsValues As ADODB.Recordset, tv As TreeView)
    rsValues.Filter = "parent_key=null"
    'Здесь можно сделать например rsValues.Sort = "Text "
    While Not rsValues.EOF
        tv.Nodes.Add , , "i" & rsValues!код, rsValues!Text
        FillSubTree rsValues.Clone, tv, "i" & rsValues!код, rsValues!Key
        rsValues.MoveNext
    Wend
End Sub

Sub FillSubTree(rsValues As ADODB.Recordset, tv As TreeView, pTreeKey As String, PKval As Long)
    rsValues.Filter = "parent_key=" & PKval
    'Здесь можно сделать например rsValues.Sort = "Text "
    While Not rsValues.EOF
        tv.Nodes.Add pTreeKey, tvwChild, "i" & rsValues!код, rsValues!Text
        FillSubTree rsValues.Clone, tv, "i" & rsValues!код, rsValues!Key
        rsValues.MoveNext
    Wend
End Sub

На больших рекордсетах этот способ не будет поражать скоростью. Зато можно избавиться от поля key, а в parent_key хранить значения поля "код".

[HandKot]

HandKot
Это прокатит, возможно только в VBNET. Стандартный treeview6, такого не умеет.

не только в НЕТ

Код: Выделить всё

Private Sub test()
    Dim nodX As Node
   
    'заполняем дерево
    Set nodX = trv.Nodes.Add(, , "q", "q")
    Set nodX = trv.Nodes.Add(, , "w", "w")
    Set nodX = trv.Nodes.Add(, , "e", "e")
    Set nodX = trv.Nodes.Add(, , "r", "r")
    Set nodX = trv.Nodes.Add(, , "t", "t")
    Set nodX = trv.Nodes.Add(, , "y", "y")
    Set nodX = trv.Nodes.Add(, , "u", "u")
   
    'проставляем парентов
    Set trv.Nodes("w").Parent = trv.Nodes("q")
    Set trv.Nodes("r").Parent = trv.Nodes("e")
    Set trv.Nodes("t").Parent = trv.Nodes("y")
   

End Sub


[Ennor]

1 заход - заполняем дерево у узлов не указываем родителя
2 заход - проставляем парентов

Вариант неплох, но уже на 10000 узлов со сложной и глубокой вложенностью время формирования дерева будет сильно больше однопроходного варианта.

Вариант Alexanbar я часто использую на стороне клиента - действительно, сортировать очень удобно. В базе этот вариант, к сожалению, практически неработоспособен по причине сильного ограничения уровня вложенности со стороны максимальной длины строкового поля в БД.

У себя в MSSQL я храню в таблице ParentId со ссылкой на первичный ключ родительского узла. Ну а отсортированное дерево получаю вызовом table-valued function, внутри которой используется цикл. Ничего лучше я не нашел, сколько ни искал. Так что, если аксесс знает, что такое UDF, хранимые в базе, то это будет, возможно, лучший вариант.

[alibek]

Увы, Access функций не позволяет.

[alibek]

Вариант неплох, но уже на 10000 узлов со сложной и глубокой вложенностью время формирования дерева будет сильно больше однопроходного варианта.

Я думаю, что для десяти тысяч узлов уже имеет смысл изменить схему данных на то, что предложил Antonariy (Nested Sets)

[Ennor]

Я думаю, что для десяти тысяч узлов уже имеет смысл

... сменить БД