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

このように固定長の文字列を使用すると、レベル - length(tree_id)/5 を簡単に計算できます。私が心配しているのは、ブランチごとに 9999 ユーザーではなく、最大 9999 ユーザーに制限されることです。私はここにいますか？

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

1 に答える 1

1

おっしゃる通りです。各ノード ID をゼロで埋めると、ツリー全体を簡単に並べ替えることができます。ただし、最後の例で指摘したように、パディング幅を ID フィールドの桁数の上限と一致させる必要があります。たとえば、int unsignedID にフィールドを使用している場合、最大値は 4,294,967,295 になります。これは 10 桁です。つまり、最後の例のレコード セットは次のようになります。

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

今後ID フィールドを に変更する必要がないことがわかっている限りbigint unsigned、これは引き続き機能しますが、テーブルがどれだけ巨大になるかによっては、データを大量に消費する可能性があります。値を 16 進数で格納することにより、ノード ID ごとに 2 バイトを削減できます。これは、文字列の並べ替えで正しく並べ替えられます。

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設定された長さにパディングする必要があり (幸いなことに、あなたの例では、各名前は 3 文字の長さのようです)、多くのスペースを占有します。

結論として、上記の問題を考えると、このような並べ替えを行う最も用途の広い方法は、アプリケーション ロジックで単純に行うことであることがわかりました。たとえば、ネストされた配列を構築する再帰関数を使用して、それぞれの子を並べ替えます。ノードはそのままです。

于 2012-05-23T17:10:56.653 に答える