Насколько хорошо / глупо было бы использовать древовидную структуру Firebase длянепосредственно представлятьпользователем облицовочный древовидная структура, как «структура документа» в «текстовых редакторах»? В отличие, например, от создание отношения типа «родитель-потомок» SQL-соединения, а затем построение дерева с помощью проекции (что, вероятно, будет медленным).

Я знаю, что существует ограничение в 32 уровня вложенности (https://www.firebase.com/docs/web/guide/understanding-data.html ), чего должно быть достаточно, поскольку я не могу представить себе здравомыслящего пользователя, желающего выполнить столько же уровней вложенности для текстового наброска дерева ... Хотя, возможно, мне нужно разделить 32 на два, поскольку каждому узлу нужно иметь подузлы для своих детей и метаданных, верно?

Я знаю, что после доступа к узлу дерева через Firebase API необходимо выбрать все подузлы, что может быть проблемой производительности, если у пользователя много данных, но в конце я думаю, что это не будет проблемой , поскольку данные в основном будут введены пользователем в виде открытого текста (короткого).

Проблема с производительностью может возникнуть, если пользователь вставит несколько очень длинных фрагментов текста, скопированного откуда-либо (например, десятки килобайт). Но тогда я мог бы отделить эти "TLOB-ы" через своего рода "символическую ссылку" в базе данных Firebase и получить их по запросу из другого узла, верно? То же самое должно применяться для разделения изображений и других тяжелых объектов, верно? Хотя на прототипе и на ранних стадиях это, вероятно, следует игнорировать, ради простоты ... Я мог бы, вероятно, применить общий подход к «символической ссылке», чтобы преодолеть ограничение в 32 уровня и необходимость извлекать все подчиненные элементы. узлы сразу, верно? Существуют ли подходы для этого (например, синтаксис для узла Firebase, который будет символизировать ссылку на другой узел)? Я извлек идею «символической ссылки» в отдельный вопрос:Firebase "символическая ссылка" на другой узел .

Я мог бы, вероятно, разделить верхние узлы на несколько видов проектов / категорий, чтобы избежать необходимости выбирать абсолютно все, что когда-либо имел пользователь ...

Верны ли мои рассуждения / подходы?

Есть ли какое-то соображение, о котором я не думал, например, врожденные ограничения на размер данных или производительность или, например,правила безопасности?

Буду ли я лучше обслуживаться другими технологиями, такими как Couchbase / Pouchbase?

Более подробная информация: это для гибридного мобильного приложения с некоторым акцентом на веб-доступ и автономный доступ. Я надеюсь сделать большую часть логики в Javascript. UI часть вопроса здесь:HTML дерево для гибридного мобильного приложения .