Quanto a questões semelhantes sobre este tema e sobre ChildEventListener, não há uma resposta relevante, então aqui está o meu.
Eu tenho um local de SQLiteDB que detém todos os dados, eu também tenho de banco de dados em tempo real Firebase que estou atualizando com novas entradas ou alterações em tempo real para todos os usuários. Atualmente estou fazendo isso com o uso de ChildEventListenercomo segue:
DatabaseReference rootRef = FirebaseDatabase.getInstance().getDatabase().getReference();
DatabaseReference childRef = rootRef.child("my_root");
ChildEventListener eventListener = new ChildEventListener()
{
....
};
childRef.addChildEventListener(eventListener);
Quanto à funcionalidade, Com este código eu posso conseguir mudanças em tempo real na criança, obter novas entradas, childs suprimidas e tudo que eu preciso, mas há um problema. Quando esta atividade específica com as cargas ouvinte para cima, o onChildAddedouvinte é chamado enormes quantidades de vezes para cada criança neste raiz, como indicado na documentação:
child_added é desencadeada uma vez para cada criança existente e, em seguida, novamente a cada vez que um novo filho é adicionado para o caminho especificado
Então eu embora a ganhar foco sobre os itens que eu realmente precisa e eu fiz-lo com:
rootRef.orderByKey().startAt("-WhatTF123456789")...
Mas então eu perdi meus recursos CRUD porque está ouvindo as novas entradas e não todos eles.
Então, eu vim com uma solução. Mantenha nó com todas as mudanças que foram feitas para o banco de dados FireBase e um nó com todos os usuários que leram e feitas as alterações ao DB local para saber quem precisa de uma atualização, então use addChildEventListenera esse nó específico. Mas isso parece redundante.
O que é as minhas opções para lidar com esse tipo de situação?
O
onChildAddedouvinte é chamado enormes quantidades de vezes para cada criança neste raiz.
Como você já mencionado e como os estados de docs, este é o comportamento esperado. Normalmente, não é recomendado para anexar um ChildEventListenerem um (nó raiz) nó que contém grande quantidade de dados. Por favor tenha cuidado sobre esta prática, porque quando o download de grande quantidade de dados, você pode obter Erros como: OutOfMemoryError . Isso está acontecendo porque você baixar implicitamente todo o nó que você está ouvindo, juntamente com todos os dados abaixo dela. Esses dados podem estar presentes como propriedades simples ou, como objetos complexos. Por isso, pode ser considerado um desperdício de recursos e largura de banda. Neste caso, a melhor abordagem é para achatar o banco de dados, tanto quanto possível. Se você é novo para bancos de dados NoSQL, esta prática é chamada desnormalizaçãoe é uma prática comum quando se trata de Firebase. Para uma melhor compreensão, eu recomendo que você dê uma olhada:
- Este vídeo, Desnormalização é normal com o banco de dados Firebase .
- Docs oficiais sobre Melhores práticas para a estrutura de dados no banco de dados em tempo real Firebase .
- Minha resposta a partir deste post: O que é desnormalização em Firebase Nuvem Firestore?
- Este artigo, Estruturação seus Dados Firebase corretamente para um aplicativo complexo .
- Neste artigo, dados NoSQL técnicas de modelagem .
Observe também que quando você está duplicação de dados, há uma coisa que precisa manter em mente. Da mesma forma que você está adicionando dados, você precisa mantê-lo. Com outras palavras, se você quiser atualizar / detele um item, você precisa fazê-lo em todos os lugares que ele existe.
Eu também recomendo que você veja a última parte da minha resposta a partir da seguinte mensagem:
É por Nuvem Firestore mas mesmas regras se aplicam ao banco de dados em tempo real Firebase.
Mas então eu perdi meus recursos CRUD porque está ouvindo as novas entradas e não todos eles.
Tudo em Firebase é de cerca de ouvintes. Você não pode obter atualizações em tempo real para objetos dentro de um nó, a menos que você está ouvindo-os. Então você não pode limitar os resultados e espera obter atualização de objetos que você não está ouvindo. Se você precisa para obter atualizações para todos os objetos dentro de um nó, você precisa ouvir a todos eles. Como essa abordagem não é prático em tudo, você pode usar desnormalização como explicado acima ou para restringir os resultados por usando consultas que podem ajudar a limitar a quantidade de dados que você começa a partir do banco de dados. Quanto às suas soluções, o segundo é muito preferido, mas você também pode considerar outra abordagem que seria para carregar dados em pequenos pedaços de acordo com uma timestamppropriedade, ou de acordo com qualquer outra propriedade que você precisa.
Edit: De acordo com o seu comentário:
Você pode fornecer testes para cada solução (1.denormalization, solução 2.my) examinar o uso de largura de banda e recursos e qual é realmente preferido?
Todos os dados são modelados para permitir que os casos de uso que um aplicativo requer. Infelizmente, eu não posso fazer testes porque ele realmente depende do caso de uso do aplicativo e a quantidade de dados que ele contém. Isto significa que o que funciona para um aplicativo, pode ser insuficiente para um outro app. Assim, os testes podem não ser correto para todos. O processo de desnormalização ou a sua solução é totalmente dependente de como você pretende para consultar o banco de dados. Na lista acima, eu adicionei um novo recurso que é uma resposta da mina em relação ao tehnique desnormalização em bancos de dados NoSQL . Espero que também os visitantes recurso de ajuda.