Firebase «symlink» на другой узел

Question

В отношении моего другого вопроса о моделировании реальной структуры дерева, обращенной к пользователю (Using firebase tree structure to represent a "document outline" structure directly), я думал о создании общего подхода к «символической привязке» на определенных уровнях гнездования до преодолеть ограничение 32 уровней вложенности и необходимость сразу получать все подузлы.

Есть ли «лучшие практики» для «символической ссылки» в firebase?

Например:

• синтаксиса (содержание, структура ключ-значение) для firebase узла, который будет символизировать ссылку на другой узел
• должен символическая содержать путь к целевому узлу (абсолютное или родственник?) или просто какой-то глобально уникальный идентификатор?
• API для обратного вызова, который будет срабатывать, когда содержание символической завершения загрузки асинхронно

Я представляя немного обертки API, который будет абстрагировать разница, действительно ли там узел или это доступ косвенно через " символическая». Может существовать дополнительный API-метод «теперь выберите меня это/больше», поскольку пользователь хочет получить более подробную информацию о отображаемых данных (например, сверлить глубже в дереве), и он может быть извлечен, например. следующий уровень вложенности (через обратный вызов), абстрагируясь от того, действительно ли было содержание детей или просто символически связано ...

Это похоже на хорошую идею вообще?

Answer 1

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

root 0 
|-- top child I 
+-- top child II 
    |-- second-level child 1 
    | +-- third-level child a 
    |-- second-level child 2 

У вас будет документ для каждого из шести узлов дерева. Затем добавьте дополнительные данные в документы, описывающие древовидную структуру.

Я был вдохновлен this SO answer, в котором излагаются три подхода с плюсами и минусами. Позвольте мне показать, как эти подходы применяются к базе данных, ориентированной на документ.

подход с родительским идентификатором

Добавить поле parentId, который содержит идентификатор документа или какой-либо другой уникальное значение родительского узла.

pros and cons: 
+ easy to understand, cheap insert, cheap subtree move 
- difficult to retrieve subtree 

Модифицированного PREORDER обходе дерева

Добавьте два поля left и right содержат индексы обхода. Сначала начните с корневого узла и назначьте 1 left, затем опустите до top child I и назначьте 2 left. Если детей больше нет, присвойте следующее целое число right. Затем перейдите на один уровень и присвойте следующее целое число right.

Для получения дополнительной информации см. Этот старый, но все же отличный справочник: Modified Preorder Tree Traversal on Sitepoint.

pros and cons: 
+ cheap retrieve of subtree, ordering of children guaranteed 
- difficult to understand, expensive insert (repeat tree traversal) 

Сохраните путь в узле

Используйте некоторое уникальное значение (например, идентификатор документа) и создать путь этих уникальных значений, начиная с корнем и нисходящие вниз к узлу. Например, путь для второго уровня 2-го уровня может быть "0/II/2". Или создайте массив ['0', 'II', '2'].

pros and cons: 
+ cheap retrieve of subtree, cheap insert 
- expensive subtree move