Flutter (Firebase) dating app, relationships between documents from the same collection-CodePudding

I'm trying to create a dating app with firebase as my NoSQL backend. However, as I'm new to the concept of NoSQL, I've encountered several problems that include optimization regarding the size of my documents and querying.

users:
       user_id
       name
       age
       gender
       location
       matches: [user1_id, user2_id, ...]
       likes_from_other_users: [user1_id, user2_id, ...]
       likes_other_users: [user1_id, user2_id, ...]
       dislikes_from_other_users: [user1_id, user2_id, ...]
       dislikes_other_users: [user1_id, user2_id, ...]

Suppose a user named UserA has lots of likes from other users therefore the size of the array likes_from_other_users will get to a point where it exceeds the maximum size of a document (1 MB). This example can apply to the other arrays.

How should I proceed?

I was thinking about extracting these large arrays to new collections.

In the case of all the likes (suppose userA has N likes from other users) to userA, there will be n documents where each document has the field 'to' set to userA id and the 'from' field set to each particular user that liked userA.

This would solve the problem of immense array sizes but may increase the complexity of querying for a particular user.

Is this the right approach? (I would have to make 5 additional collections: likes_from_other_users, likes_other_users, dislikes_from_other_users, dislikes_other_users, and matches) and may be slow.

Additionally, the matches collection would contain a pair (array) of users, so to query the matches for a particular user, I would need to check all the documents in this collection and find those that contain the particular user that I'm querying for

Is this the right approach?

CodePudding user response：

I was thinking about extracting these large arrays to new collections.

This is the only scalable solution. Arrays are not scalable at all; individual documents within a collection is infinitely scalable in Firestore. It's not even a question as to whether this is the "right" solution, it's the only scalable solution when using Firestore.

Note that Firestore is not always the best database for a given application. If you're concerned about the cost or efficiency of a solution for a given problem, maybe Firestore isn't really the best solution. Each database has its strengths, and NoSQL database are typically not good at expressing complex relationships like SQL databases are.