3

浏览整个网络上的示例，我可以看到人们使用“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

但正如这个问题中所解释的 -使用物化路径排序树？，对 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.??
4

1 回答 1

1

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

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

只要您知道bigint unsigned将来不需要将 ID 字段更改为，这将继续工作，尽管根据您的表有多大，它可能会有点数据饥渴。您可以通过以十六进制存储值来减少每个节点 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

但是，正如这个人对类似物化路径排序问题的回答所阐述的那样，存在局限性。该name字段必须填充到设定的长度（幸运的是，在您的示例中，每个名称似乎都是三个字符长），并且会占用大量空间。

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

于 2012-05-23T17:10:56.653 回答