Лучший способ создать шаблон пути для материализованных структур дерева путей

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

Но, как объяснено в этом вопросе - Сортировка дерева с материализованным путем? , с использованием дополнения нулями до 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, как вы указали в последнем примере. Например, если вы используете поле int unsigned для своего идентификатора, самое высокое значение будет 4 294 967 295. Это десять цифр, это означает, что набор записей из вашего последнего примера может выглядеть следующим образом:

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

Пока вы знаете, что в будущем вам не понадобится менять поле идентификатора на bigint unsigned, это продолжит работу, хотя это может быть связано с большими объемами данных в зависимости от размера ваших таблиц. Вы можете сократить два байта на каждый идентификатор узла, сохранив значения в шестнадцатеричном формате, которые все равно будут правильно отсортированы при сортировке строк:

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 должно быть заполнено до заданной длины (к счастью, в вашем примере каждое имя имеет длину в три символа), и оно заняло бы много места.

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