Запросы Firebase теперь могут запрашивать вложенные пути, но пути не могут быть динамическими.
Так что, если вы знаете идентификатор пользователя, вы можете запросить архивы этого пользователя с:
ref.child(authData.uid).orderByChild('foo').equalTo(1).on(...
Если вы не знаете идентификатор пользователя, то вам придется создать структуру данных, что позволяет сделать что поиск:
archive_category_to_uids: {
foo: {
1: {
uid1: true,
uid2: true
}
}
}
более распространенным способом является разделение архивов в их собственный список верхнего уровня и имеют как пользователей, так и категории относятся к тому, что:
users: {
userId1: {
archiveKey1: true,
...
},
...
},
archives: {
archiveKey1: {
foo: 1,
uid: uid1
},
...
},
archiveCategories: {
foo: {
1: {
archiveKey1: true,
archiveKey2: true
}
}
}
Теперь вы можете получить найти архивы:
ref.child('archiveCategories/foo/1').once('value', function(keys) {
keys.forEach(function(key) {
ref.child('archives').child(key.key()).once('value', function(snapshot) {
console.log(snapshot.val());
});
};
});
Этот процесс называется денормализация и является довольно распространенным в базах данных NoSQL. Вы моделируете данные о том, как ваше приложение должно потреблять его. Для получения дополнительной информации об этом и других распространенных шаблонах, я рекомендую прочитать это article on NoSQL data modeling.
В Firebase нет стандартной системы запросов, вам нужно структурировать свои данные, чтобы читать ваши приложения. Так что да, вам нужно вручную выкопать или найти структуру данных, которая соответствует вашим потребностям. – Th0rndike
AFAIK, это только отчасти верно. Вы глубоко вложены в статические дочерние элементы, такие как 'orderByChild ('child1/child2')'. Мой вопрос заключается в том, возможно ли это делать с динамическими детьми. – Martol1ni