update query firestore data consultas complejas array database firebase nosql data-modeling google-cloud-firestore

database - data - firestore query



Trabajando con consultas Ășnicas anidadas en Firestore (1)

Recientemente cambié mi modelo de datos de Firebase a Firestore. Todo mi código está funcionando, pero estoy teniendo algunos problemas desagradables con respecto a mis consultas anidadas para recuperar algunos datos. Aquí está el punto:

En este momento, mi modelo de datos para esta parte se ve así (Sí, otro ejemplo de seguidores / feed):

{ "Users": { //Collection "UserId1" : { //Document "Feed" : { //Subcollection of Id of posts from users this user Follow "PostId1" : { //Document "timeStamp" : "SomeDate" }, "PostId2" : { "timeStamp" : "SomeDate" }, "PostId3" : { "timeStamp" : "SomeDate" } } //Some data } }, "Posts":{ //Collection "PostId1":{ //Document "Comments" :{ //Subcollection "commentId" : { //Document "authorId": "UserId1" //comentsData } }, "Likes" : { //Subcollection "UserId1" : { //Document "liked" : true } } } } }

Mi problema es que para recuperar las Publicaciones de la fuente de un usuario debo consultar de la siguiente manera:

  • Obtenga el último orderer de documentos X por timeStamp de mi fuente

feedCol(userId).orderBy(CREATION_DATE, Query.Direction.DESCENDING).limit(limit)

  • Después de eso, debería hacer una única consulta de cada publicación recuperada de la lista: workoutPostCol.document(postId)

  • Ahora tengo los datos de cada publicación, pero deseo filmar el nombre de usuario, la imagen, los puntos ... etc. del autor, que está en un Document diferente, así que, de nuevo, debo hacer otra consulta individual para cada authorId recuperado en la lista de mensajes userSocial(userId).document(toId)

  • Finalmente, y no menos importante, necesito saber si mi usuario actual ya me gustó esa publicación, así que tengo que hacer una única consulta para cada publicación (nuevamente) y verificar si mi userId está dentro de las posts/likes/{userId}

En este momento todo está funcionando, pero pensando que el precio de Firestore depende de la cantidad de llamadas a la base de datos, y también que no hace mis consultas más simples, no sé si es solo que mi modelo de datos no es bueno. para este tipo de base de datos y debería pasar a SQL normal o simplemente volver a Firebase nuevamente.

Nota : Sé que TODO, sería mucho más fácil mover estas subcolecciones de me gusta, feed, etc. a listas de arreglos dentro de mi usuario o publicar documentos, pero el límite de un Documento es de 1MB y si esto crece demasiado, se bloqueará en el futuro. Por otro lado, Firestore no permite consultas de subdocumento (aún) o una cláusula OR que usa múltiples whereEqualTo .

He leído muchas publicaciones de usuarios que tienen problemas para buscar una forma sencilla de almacenar este tipo de relación de ID''s para realizar joins y queries en sus Collections , el uso de Arraylists sería increíble, pero el límite de 1 MB lo limita mucho.

Espero que alguien pueda aclarar esto, o al menos enseñarme algo nuevo; tal vez mi modelo es simplemente basura y hay una manera simple y fácil de hacer esto? O tal vez mi modelo no es posible para una base de datos que no sea sql.


No estoy seguro al 100% si esto resuelve el problema por completo, ya que puede haber casos extremos para su uso. Pero con un pensamiento rápido de 5 minutos, siento que lo siguiente podría resolver su problema:

Puede considerar usar un modelo similar al de Instagram. Si mi memoria me sirve, lo que usan es una colección basada en events . Por events en este contexto específico me refiero a todas las acciones que realiza el usuario. Entonces, un comment es un evento, un me like es un evento, etc.

Esto lo haría para que necesites tres colecciones principales en total.

users -- userID1 ---- userdata (profile pic, bio etc.) ---- postsByUser : [postID1, postID2] ---- followedBy : [userID2, ... ] ---- following : [userID2, ... ] -- userID2 ---- userdata (profile pic, bio etc.) posts -- postID1 (timestamp, so it''s sortable) ---- contents ---- author : userID1 ---- authorPic : authorPicUrl ---- authorPoints : 12345 ---- taggedUsers : [] ---- comments ------ comment1 : { copy of comment event } ---- likes : [userID1, userID2] -- postID2 (timestamp) ---- contents ... events -- eventID1 ---- type : comment ---- timestamp ---- byWhom : userID ---- toWhichPost : postID ---- contents : comment-text -- eventID2 ---- type : like ---- timestamp ---- byWhom : userID ---- toWhichPost : postID

Para su página de usuario-bio, consultaría a los users .

Para el suministro de noticias, consultaría las posts de todos los mensajes por los ID de usuario que su usuario esté siguiendo en el último día (o cualquier intervalo de tiempo dado),

Para la página de alimentación de actividad (comentarios / Me gusta, etc.), consultaría los events que son relevantes para su ID de usuario limitados al último día (o cualquier intervalo de tiempo dado)

Finalmente, consulte los días siguientes para publicaciones / eventos a medida que el usuario se desplaza (o si no hay actividad nueva en esos días)

De nuevo, esto es solo una idea rápida, sé que los ancianos de SOF tienen la costumbre de crucificarlos por lo general, así que perdónenme a los miembros de SOF si esta respuesta tiene defectos :)

Espero que ayude a Francisco,

¡Buena suerte!