This is a creation in Article, where the information may have evolved or changed.
Http://studygolang.com/wr?u=http%3a%2f%2f88250.b3log.org%2fgolang-ztree
Package Mainimport ("Encoding/json" "FMT" "OS" "Path/filepath" "sort") Func main () {rootpath: = "d:\\projects" root: = filenode{"Projects", RootPath, []*filenode{}}fileinfo, _: = OS. Lstat (RootPath) walk (RootPath, FileInfo, &root) data, _: = json. Marshal (Root) fmt. Printf ("%s", data)}type filenode struct {name string ' JSON: ' Name ' ' Path string ' JSON: ' path ' ' filenodes [ ]*filenode ' JSON: "Children" '}func Walk (path string, info OS. FileInfo, node *filenode) {//List all directories in the current directory, file files: = listfiles (path)//Traverse These files for _, FileName: = Range Files {//stitching full path Fpat H: = FilePath. Join (path, filename)//construct file Structure Fio, _: = OS. Lstat (Fpath)//Add the current file as a child node to the directory: = Filenode{filename, Fpath, []*filenode{}}node. Filenodes = Append (node. Filenodes, &child)//If the current file being traversed is a directory, enter the directory for recursive if Fio. Isdir () {Walk (Fpath, Fio, &child)}}return}func listfiles (dirname string) []string {F, _: = OS. Open (dirname) names, _: = F.readdirnames ( -1) f.close () sort. Strings (names) return names}
Using the inner loop of the ego-that is, infinite recursion-avoids the silly way it used to be: A Level 4 menu is nested with 4 structs. and loop for is also 4 layers.
If Fio. Isdir () {Walk (Fpath, Fio, &child)}
Enables infinite-level struct nesting and turns it into JSON for use by the TreeView, which is an infinite-level tree-like menu.
The database structure is made of traditional parentid that can be understood, without the kind of left and right trees: https://segmentfault.com/q/1010000000126370/a-1020000000126714
Well, I forgot to mention a very dirty method.
If your tree depth is predictable, there is a super-simple data structure. You need 3 fields to express the tree:
- ID, primary key for this node
- PARENT_ID, whose value is primary key of the parent node
- Key, forget what the scientific name is, you can call it a clue.
- Level, which represents the distance from the current node to the root node
Where the value of the key field is: From the node to the parent node primary key, in the middle with any non-numeric symbol segmentation.
For example the following tree-like structure
├──a│├──d││├──p││├──q││└──r│├──e│└──f├──b│├──x│├──y│└──z├──c
The corresponding database table values are:
| ID | Value | parent_id | Key | Level | |1| A |0|"-"|1||2| B |0|"-"|1||3| C |0|"-"|2||4| D |1|"1-"|2||5| e |1|"1-"|2||6| f |1|"1-"|2||7|x|2|"2-"|2||8|y|2|"2-"|2||9| Z |2|"2-"|2||Ten| P |4|"1-4-"|3|| One|Q | 4 | "1-4-"|3|| A| R |4|"1-4-"|3|
So, given a node D,
- Find all descendant nodes of D:
select * from table_name where key like "${d.key}-${d.id}-%"
- To find all child nodes of a node:
select * from table_name where key like "${d.key}-${d.id}-%" and level=${d.level}+1
This design, the structure is very simple. Key and level are secondary fields, and maintaining these two fields is very inexpensive, even if all rebuilds are much simpler than MPT.
Yegle 2.5k Prestige Yegle's data wrong, right? The root node's key should be "". Find all descendant nodes of D should be SELECT * FROM table_name where key like "${d.key}${d.id}-%" find child nodes should be: SELECT * FROM table_name where key lik E "${d.key}${d.id}-%" and level=${d.level}+ 1
Rory_ye · June 28, 2014
+1
Indeed, it should be according to the @rory_ye said. Otherwise, the first-level node cannot view its descendants node.
Faker · June 3
I just went to see modified preorder Tree, and I have a question about if I add a byte point, then the database table is not all changed? This tree is similar to a line tree.
Tansumanong · June 8
When I did not say, originally is the database, I thought is Java web, haha
Tansumanong · June 8
Is it efficient to use like when querying?
play175 · July 7