En cuanto a las preguntas similares sobre este tema y sobre ChildEventListener, no hay una respuesta relevante, por lo que aquí está la mía.
Tengo un local de SQLitebase de datos que contiene todos los datos, también tengo la base de datos en tiempo real Firebase la que estoy actualizando con nuevas entradas o cambios en tiempo real a través de todos los usuarios. Actualmente lo estoy haciendo con el uso de ChildEventListenerla siguiente manera:
DatabaseReference rootRef = FirebaseDatabase.getInstance().getDatabase().getReference();
DatabaseReference childRef = rootRef.child("my_root");
ChildEventListener eventListener = new ChildEventListener()
{
....
};
childRef.addChildEventListener(eventListener);
En cuanto a la funcionalidad, con este código que puedo conseguir cambios en tiempo real en child, obtener nuevas entradas, childs eliminadas y todo lo que necesita, pero hay un problema. Cuando esta actividad específica con las cargas de hasta oyente, el onChildAddedoyente se llama a una enorme cantidad de veces por cada niño en esta raíz, como se indica en la documentación:
child_added se dispara una vez por cada niño existente y luego de nuevo cada vez que se agrega un nuevo niño en la ruta especificada
Así que, aunque para obtener el foco en los artículos que realmente necesita y lo he hecho con:
rootRef.orderByKey().startAt("-WhatTF123456789")...
Pero entonces he perdido mis capacidades CRUD porque está escuchando a las nuevas entradas y no todos ellos.
Así que se me ocurrió una solución. Mantenga nodo con todos los cambios que se han realizado a base de fuego la base de datos y un nodo con todos los usuarios que hayan leído y realizados los cambios en la base de datos local para saber quién necesita una actualización, a continuación, utilizar addChildEventListenera este nodo específico. Pero eso parece redundante.
¿Cuál es mi opciones para manejar este tipo de situaciones?
El
onChildAddedoyente se llama a una enorme cantidad de veces por cada niño en esta raíz.
Como ya lo ha dicho, y como dice el doc, este es el comportamiento esperado. Por lo general, no se recomienda adjuntar una ChildEventListeneren un nodo (nodo raíz) que contiene gran cantidad de datos. Tenga cuidado con esta práctica, porque cuando la descarga de gran cantidad de datos, puede obtener erros como: OutOfMemoryError . Esta situación se debe descargar de forma implícita todo el nodo que se está escuchando, junto con todos los datos por debajo de él. Que los datos podría estar presente como propiedades simples o, como objetos complejos. Por lo tanto, se puede considerar un desperdicio de recursos y ancho de banda. En este caso, el mejor enfoque consiste en aplanar la base de datos tanto como sea posible. Si usted es nuevo en las bases de datos NoSQL, esta práctica se llama desnormalizacióny es una práctica común cuando se trata de Firebase. Para una mejor comprensión, le recomiendo que eche un vistazo a:
- Este video, Desnormalización es normal con la base de datos Firebase .
- Documentos oficiales sobre mejores prácticas para la estructura de datos en la base de datos en tiempo real Firebase .
- Mi respuesta a esta entrada: ¿Cuál es la desnormalización en Firebase Nube Firestore?
- En este artículo, Estructuración de sus Datos Firebase correctamente para una aplicación compleja .
- En este artículo, los datos NoSQL técnicas de modelación .
Tenga en cuenta también que cuando se está duplicando los datos, hay una cosa que hay que tener en cuenta. De la misma manera que está añadiendo datos, es necesario para mantenerla. Con otras palabras, si quiere actualizar / detele un elemento, que tiene que hacer en cada lugar que existe.
También recomiendo que veas la última parte de mi respuesta desde el siguiente mensaje:
Es por la nube, pero Firestore mismas reglas se aplican a la base de datos en tiempo real Firebase.
Pero entonces he perdido mis capacidades CRUD porque está escuchando a las nuevas entradas y no todos ellos.
Todo en Firebase se trata de los oyentes. No se puede obtener actualizaciones en tiempo real de los objetos dentro de un nodo, a menos que esté escuchando a ellos. Así no se puede limitar los resultados y esperar para obtener actualizaciones de objetos que no están escuchando. Si usted necesita para obtener actualizaciones para todos los objetos dentro de un nodo, es necesario escuchar a todos ellos. Debido a que este enfoque no es práctico en absoluto, puede uso desnormalización como se explicó anteriormente, o para restringir los resultados por el uso de consultas que pueden ayudar a limitar la cantidad de datos que se obtiene de la base de datos. En cuanto a sus soluciones, la segunda es mucho más preferido pero también se puede considerar otro enfoque que sería para cargar datos en trozos más pequeños de acuerdo a una timestamppropiedad, o según cualquier otra propiedad que usted necesita.
Editar: De acuerdo con su comentario:
¿Puede usted por favor proporcione pruebas para cada solución (1.denormalization, solución 2.my) examinar el uso de ancho de banda y recursos y cuál es realmente preferido?
Todos los datos se modela para permitir que los casos de uso que requiere una aplicación. Por desgracia, no puedo hacer las pruebas, ya que realmente depende del caso de uso de la aplicación y la cantidad de datos que contiene. Esto significa que lo que funciona para una aplicación, pueden ser insuficientes para otra aplicación. Por lo que las pruebas podrían no ser correcta para todos. El proceso de desnormalización o su solución depende totalmente de cómo se va a consultar la base de datos. En la lista anterior, he añadido un nuevo recurso que es una respuesta mía en cuanto a la tehnique desnormalización en bases de datos NoSQL . Esperamos que se puede también visitantes función de ayuda.