Question

浏览整个网络上的示例，我可以看到人们使用类似“parent_id.node_id”的内容生成路径。示例： -

uid | name | tree_id
--------------------
 1  | Ali  |   1.
 2  | Abu  |   2.
 3  | Ita  |   1.3.
 4  | Ira  |   1.3.
 5  | Yui  |   1.3.4

但正如本问题中所解释的那样 - Sorting tree with a materialized path?，对tree_id使用零填充可以很容易地按创建顺序对其进行排序。

uid | name | tree_id
--------------------
 1  | Ali  |   0001.
 2  | Abu  |   0002.
 3  | Ita  |   0001.0003.
 4  | Ira  |   0001.0003.
 5  | Yui  |   0001.0003.0004

使用这样的修复长度字符串也可以让我轻松计算级别 - 长度（tree_id）/ 5。我担心的是它会限制我最多9999个用户而不是每个分支9999个。我在这儿吗？

9999  | Tar | 0001.9999
10000 | Tor | 0001.??

Answer 1

你是对的 - 零填充每个节点ID将允许你非常简单地对整个树进行排序。但是，您必须使填充宽度与ID字段的数字上限相匹配，正如您在上一个示例中指出的那样。例如，如果您使用int unsigned字段作为您的ID，则最高值为4,294,967,295。这是十位数，这意味着您上一个示例中的记录集可能如下所示：

uid   | name | tree_id
9999  | Tar  | 0000000001.0000009999
10000 | Tor  | 0000000001.0000010000

只要您知道将来不需要将ID字段更改为bigint unsigned，这将继续工作，但可能会有点数据需求，具体取决于您的表格有多大得到。您可以通过以十六进制存储值来节省每个节点ID两个字节，这仍然可以在字符串排序中正确排序：

uid   | name | tree_id
9999  | Tar  | 00000001.0000270F
10000 | Tor  | 00000001.00002710

我可以想象，当尝试更新路径（修剪节点等）时，这会让事情变得非常令人头疼。

您还可以创建额外的字段进行排序，例如：

uid   | name | tree_id           | name_sort
9999  | Tar  | 00000001.0000270F | Ali.Tar
10000 | Tor  | 00000001.00002710 | Ali.Tor

然而，正如this guy's answer to a similar materialized path sorting question所述，存在一些局限性。 name字段必须填充到设定长度（幸运的是，在您的示例中，每个名称似乎长度为三个字符），并且会占用大量空间。

总之，鉴于上述问题，我发现像这样进行排序的最通用的方法是在你的应用程序逻辑中简单地做 - 比如，使用构建嵌套数组的递归函数，对它进行排序每个节点的子节点。

为物化路径树结构生成路径模式的最佳方法

1 个答案: