获取有关单个查询中用户是否喜欢该供稿的信息（Firestore） [英] Get information if the feed is liked by the user in a single query (Firestore)
问题描述
我想为我的用户显示提要。
每个帖子都有一个赞按钮（例如在Twitter，Instagram ...中）
如果帖子已被喜欢或不喜欢，我想显示一个不同的图标。
I want to show feeds for my users.
Every post has a "like" button (like in twitter, Instagram...)
I want to show a different icon if the post is already liked or not.
我现在面临的问题是，如果用户已经喜欢该帖子，我找不到一种经济的方式来获取信息。最好的方法是是否可以通过单个查询获得此信息。我有两种想法，我认为这不是最好的方法。
The problem I'm facing right now is, that I couldn't find an economical way to get the information if the post is already liked by the user. The best way would be if I could get this information with a single query. I have two ways in my mind which I think isn't the best way yet.
-
每次用户加载供稿时查询用户喜欢的收藏集
此每个加载的帖子将花费2个查询，这在性能和计费方面可能是昂贵的。例如，观看20个帖子将花费40个查询。
Query the users "liked" collection, every time he loads a feed
This would cost 2 queries per loaded post, which could be expensive in performance and billing perspective. For example, watching 20 posts would cost 40 queries.
一次下载所有喜欢的帖子并离线查询
我可以检查用户是否已通过客户端方式喜欢给定的帖子。但这会喜欢帖子的用户一次加载许多不必要的数据。
Download all liked posts for once and query offline
I could check if the given post is already liked by the user in a client side way. But this would load many needless data at once by a user who "likes" to give likes to posts.
我对我的想法正确吗？是否有更好的方法来解决此问题，而又不会使账单和性能变得太昂贵？
Am I right with my thoughts? Is there a better way to solve this problem without being too expensive for billing and performance?
推荐答案
要解决like /问题与您的帖子不同，@ Hudson Hayes在回答中也提到过，我还建议您尝试以下模式：
To solve the problem of like/unlike for your posts, as also @Hudson Hayes mentioned in his answer, I also recommend you try the following schema:
Firestore-root
|
--- posts (collection)
|
--- postId (document)
|
--- //Post details
|
--- userLikes: ["userIdOne", "userIdTwo", "userIdThree"]
如您所见，在每个 Post 对象下，都有一个包含用户ID的数组。现在，每次用户喜欢帖子时，只需将其ID添加到 userLikes 数组中即可。当用户撤消诸如此类的请求时，只需从数组中删除其ID即可。在这种情况下，您只需要为每个喜欢/不喜欢的用户支付一次写操作。
As you can see, under each Post object there is an array that contains user ids. Now, everytime a user likes a post, simply add his id to the userLikes array. When the user revokes the like, simply remove his id from the array. In this case you'll be charged only with one write operation for each like/unlike.
现在可以显示所有帖子的列表并突出显示喜欢和不喜欢的帖子，只需创建一个包含posts对象的列表。因为您知道经过身份验证的用户的ID，所以只需在每个 userLikes 数组中检查其ID是否存在。如果它的id存在于数组中，则显示红色的心，否则显示灰色的心。
Now to display a list of all posts and highlight which is liked and which not, simply create a list that contains posts objects. Because you know the id of the authenticated user, simply check the existence of its id in each post userLikes array. If its id exist in the array show a red heart otherwise show a grey one.
不需要其他查询。因此，恕我直言，您的解决方案均不适用于此用例。
There is no need for additional queries. So IMHO, none of your solutions might apply to this use-case.
编辑：
文档的大小确实是1MiB，但是当我们谈论存储文本（用户ID）时，您可以存储很多。
The size of the document is indeed 1MiB but when we are talking about storing text (user ids), you can store pretty much.
如果是，那么对于扩展应用程序来说不是解决方案。
If yes, this wouldn't be a solution for a scaling application.
是的，它是一种扩展解决方案。 1Mib可以容纳1,000,000个字符，id为20的字符数等于50,000。如果您认为自己的应用会如此受欢迎，那么一篇帖子就会超过最多5万个顶的赞，是的，这不是一个选择。但是有一种解决方法。然后，您可以创建一个子集合，该子集合将记录喜欢的文档。每个文档将包含50,000个ID。因此，对于150,000个赞，您将只有3个文档。要检查一下，对于每个帖子，您都需要创建一个额外的查询来获得点赞的次数（在上面的示例中为三个），并查看其中是否包含用户ID。
Yes, it is a solution for scaling. 1Mib can hold 1,000,000 chars, divided to 20, the number of chars an id has, it means 50,000. If you think that your app will be so popular, so a single post will exceed the max number of 50,000 of likes, yes, it's not an option. But there is an workaround. You can create then a subcollection that will documents of likes. Each document will hold 50,000 ids. So for 150,000 likes, you'll have only 3 documents. To check that out, for every post you'll need to create an extra query to get the number of likes (in the above example three) and see if user id is in it.
将喜欢存储为单个对象不是一种选择，因为对于150,000个喜欢，您将被收取150,000个读操作，这太昂贵了。
Storing the likes as individual objects is not an option since for 150,000 likes you'll be charged with 150,000 read operation which is too expensive.
此外，这也是一个附加查询，因为如果用户不在Likers数组中，我将无法获取帖子数据。
Furthermore it would be an additional query as well, because I couln't get the post data if the user isn't in the likers array.
您可以获得所需的任何数据，但请记住，您不查询用户集合，而是查询帖子集合。此收藏集包含所有用户的帖子。如果需要查看单个用户的帖子，请在名为 createdBy 的文档内添加一个属性，并添加创建该用户的用户的ID。然后需要这样的查询：
You can get any data you want but remember, you don't query the users collection, you query the posts collection. This collection holds the posts of all users. If you need to see the posts of a single user, add a property inside the document named, createdBy and add the id of the user who created it. Then a query like this is required:
db.collection("posts").whereEqualTo("createdBy", uid);
要克服这一点，我必须加载完整的数组并对其进行过滤在客户端。
To overcome this I would have to load the complete array and filter it on the client side.
没有必要。我在上面解释了原因。
There is no need for that. I explained above why.
这篇关于获取有关单个查询中用户是否喜欢该供稿的信息（Firestore）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
