Я хочу получить общее число, пока не указано.
это моя база данных: изображение базы данных
Я хочу посчитать, где ticket_status
находится not served
пример: я хочу считать до A6
, я буду считать A1
до A5
, где значение ticket_status"
равно not served
. так что окончательный счет будет 3.
есть ли какая-то фильтрация?
У меня есть этот код, но он просто считает все узлы со значением «не обслуживается».
dbref.child("Queue").child(a.value.toString()).orderByChild("ticket_status").equalTo("not served").addValueEventListener(object : ValueEventListener{
override fun onDataChange(snap: DataSnapshot) {
val count = snap.childrenCount
dbref.child("Student_Queue_Reserve").child(idNumber.toString()).child("people_ahead").setValue((count-1).toString())
}
override fun onCancelled(error: DatabaseError) {
}
})
код работает нормально, он читает и считает дочерний элемент со значением «ticket_status» «не обслуживается». на скриншоте я предоставил 8 дочерних элементов. 2 этого дочернего элемента имеют значение «обслуживается» в их «ticket_status». Код будет отображаться как 6, потому что он считает всех дочерних элементов со значением «не обслуживается». я хочу, чтобы я хотел читать только до указанного дочернего ключа. например, я хочу прочитать и подсчитать, где значение «ticket_status» «не обслуживается» до «A5» (см. снимок экрана). A1 и A2 «обслуживаются», а «A3», «A4», «A5» «не обслуживаются». я ожидаю, что результат будет 2,2, потому что "A5" - последний узел
Я хочу считать до
A6
, я буду считатьA1
доA5
, где значениеticket_status"
равноnot served
. Таким образом, окончательный счет будет 3.
Вы не можете сделать это в базе данных реального времени, потому что запросы могут упорядочивать/фильтровать только одно свойство. В некоторых случаях вы можете объединить значения, которые хотите отфильтровать, в одно свойство. Например, проверьте мой ответ ниже:
Если вам разрешено изменять схему базы данных, вам следует рассмотреть возможность денормализации данных. Таким образом, структура, подобная приведенной ниже, сделает свое дело:
db
|
--- Queue
|
--- Accounting Office
|
--- served
| |
| --- A1
| | |
| | --- serving_token: "A001"
| | |
| | --- ticket_status: "served"
| |
| --- A2
| |
| --- serving_token: "A002"
| |
| --- ticket_status: "served"
|
--- not served
|
--- A3
| |
| --- serving_token: "A003"
| |
| --- ticket_status: "not served"
|
--- A4
| |
| --- serving_token: "A004"
| |
| --- ticket_status: "not served"
|
--- A5
| |
| --- serving_token: "A005"
| |
| --- ticket_status: "not served"
|
--- A6
|
--- serving_token: "A006"
|
--- ticket_status: "not served"
Теперь вы можете запросить «необслуживаемый» узел, используя комбинацию Query#orderByKey() и Query#endAt(java.lang.String)
db.child("Queue").child("Accounting Office").child("not served").orderByKey().endAt("A6");
Вы можете попробовать этот подход без запроса:
ArrayList servedArray ;
ArrayList notServedArray ;
И для подсчета вы можете использовать:
servedArray.size
notServedArray.size
Это означает, что OP загружает весь узел и выполняет фильтрацию на клиенте, верно? Не дорого ли это?
В документации Firebase говорится: «Примечание: фильтрация и сортировка могут быть дорогими, особенно когда они выполняются на клиенте ...», поэтому я избегал опции запроса. Я так не думаю, если максимальный размер узла составляет 1000 токенов.
Да, это правильно, фильтрация и сортировка могут быть дорогими, особенно когда они выполняются на клиенте. И насколько я понимаю, это то, что рекомендует ваш ответ.
Большое спасибо, я ошибался, я думал, что термин «дорогой» относится к выставлению счетов Firebase.
Я не уверен, что понимаю. Что именно в этом коде работает не так, как вы ожидаете?