Как правило, структуры Firebase зависят от типов запросов, которые вы собираетесь использовать.IMO - это часто лучшая практика для отделения ключей узла от данных, которые они содержат, особенно если ключ узла может быть динамическими данными, такими как электронная почта или имя пользователя, которые могут измениться в будущем.
Я изложу этоответьте, приведя примеры того, почему
"posterUID:postID"
может быть плохим.
Само собой разумеется, что вам необходим код для кодирования / декодирования ключей узла, так что это просто дополнительный код.
Проблема № 1: Что, если один и тот же пользователь дважды публикует сообщение?
uid
posterUID:postID
timeStamp: 583190375
posterUID:postID
timeStamp: 123456789
Ах, вы не можете этого сделать, поскольку у вас не может быть дубликатов ключей в одном и том жеnode
Issue # 2: Запросы любого типа по конкретному сообщению невозможно выполнить без чтения всех узлов и фильтрации кода.Это может быть много данных или избыточность
Проблема № 3: Получение всех сообщений о конкретном сообщении от любого отслеживаемого пользователя.Firebase не поддерживает частичные завершающие строковые запросы.
Проблема № 4: Post_1234 была удалена, и теперь мне нужно удалить ссылки на этот узел из "uid"узел.Что ж, этого не произойдет без чтения во всех дочерних узлах.
Существует ряд дополнительных проблем, с которыми может столкнуться, но они не могут быть решены без понимания всего объемакакие запросы могут быть выполнены.
Это более гибкое решение
Post_Timeline
uid
randomID
timeStamp: 583190375,
posterUID: "JNFSD78436VSFFDSF"