Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am building a social media app and currently, I am storing Usernames, Users, and Posts in Firestore. I am afraid that it will be expensive if there are lots of users(around 50,000). So I planned to store half of the data in Firestore and other half in Realtime Database. Now I am confused if should store the Posts or the Users in Realtime Database. In which database should I put the Posts (Realtime or Firestore)?
Better to stick with 1 source of truth. Between the two I would choose firestore.
There is a pretty good comparison between the two and their tradeoffs here. Do you care only about mobile or do you want your app to work on web and mobile? I'd go with firestore if that is the case.
https://firebase.google.com/docs/database/rtdb-vs-firestore
Also you mention you have Usernames, Users, and Posts in your database. You should be storing usernames in your "Users" collection so you would really only have two different collections for these "Users" and "Posts". Also between the two, you are likely going to have more posts than there are users.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I want to get subscriptions of users.
I can get user one by one then get each user subscriptions.
But this will make many document reads.
i want to get subscriptions 10 by 10 sorted by newest.
is that possible?
Firestore path
we can get users one by one then get each user subscription but this will make many reads
It doesn't matter if you get the documents one by one, or all documents at once, you'll always pay the same price. What I mean is that if you perform a query that returns 5 documents, you'll have to pay 5 read operations. If you read each of those 5 documents, one by one, the same number of read operations you have to pay.
I want to get subscriptions 10 by 10 sorted by newest is that possible?
In that case, you have to perform a query. For that, I recommend you start with the official documentation.
Subcollections: Firestore query subcollections
Pagination: https://firebase.google.com/docs/firestore/query-data/query-cursors
Be aware that asking questions in this way lowers the chances of getting answers.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I am developing an app that the users can upload and vote for TagImages, so what is needed is to when someone check into a TagTopic get the most popular images and the newest one, so to do this ranking operation.
How should I approach this?
I think what you need is to use Firestore or Realtime, but in you case realtime would be better because the number of reads and writes, however, what you could do is to create an object for each image that contains the metadata about it like the number of votes, may be also down votes, who upload it, upload time, tags, or any things else you want. Then in you app or website you'll make a query that reads lets say top 5, and get them, then use the images names to get them from the cloud storage. For example:
images:{
image1Name:{
upvote: 10;
downvote: 2;
totolvote: 8;
uploader: 'Remoo';
uploadTime: '10:00:00AM 23/11/2021' //whatever the structure
}
}
Then you query them (this is Flutter example):
_firebaseDatabase
.reference()
.child("images")
.orderByChild('totolvote')
.limitToFirst(5)
.once().then(()=>{...})
Then get image1Name from cloud storage.
But note you can only use one orderByChild with each query, on the other hand you can use multiple where in Firestore, but there will be more cost on the reads and writes. Eventually it up to you and how you structure it. Hope this work for you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I want to ask which is best for this case to implement in Firestore?
For instance, I have a list of transactions.
In this list, I want to:
Query and Sort.
Full-text search using Algolia.
Apply rules.
Should I use root collection which contains all transactions from all users, or create a sub-collection named transactions in each user?
A solution I look at should be efficient at cost and performance.
I have read:
https://firebase.googleblog.com/2019/06/understanding-collection-group-queries.html
But no mention for Algolia.
I also have read Algolia docs, but there is no tutorial on how to implement Algolia search on sub-collection using the firebase extension.
If you want to index documents in a sub-collection you can use a wildcard as shown below:
users/{userId}/transactions
It's mentioned in the extension's Github home page here.
About root level collection vs sub-collections, you can check this answer by #Alex:
What are the benefits of using a root collection in Firestore vs. a subcollection?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm currently going through the process of making sure my Woocommerce websites are compliant with the GDPR legislation coming into effect, May 25th. The default way Woocommerce works is that it stores every order in the database so customers are able to view their previous orders and the admins can process them.
My question is.. Should I introduce a way customers can delete their own orders? Or a maximum amount of time I hold onto these before automatically deleting?
Is there an industry standard for this?
Thanks in advance
What you're looking at is the right for no longer relevant data to be erased. Keep in mind this is different from the right to be forgotten. This does not need to be a programatic thing. Sites like Facebook and Google give a set of admin controls to do this so they don't need to process hundreds of thousands of users individually. The rules state 30 days from request.
A note in site terms on an email to contact to have your data deleted really should suffice. Again keep in mind it is legal to keep sales data, only specific data may be requested to be destroyed. This is paramount in an e-commerce environment.
There are WP plugins to allow users to delete their account but this may cause issues with WC.
A good place to start is with WooCommerces own blog post on the issue
https://woocommerce.com/2017/12/gdpr-compliance-woocommerce/
For full detail of the right of erasure check here
https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-erasure/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
i'n trying to figure out, what's the best practice for building collections associated with user's data.(In terms of reactive, queries speed, or other.)
For example, what's better?
Meteor.Users.profile: {friends, likes, previous orders, locations, favorites, etc"}.
Or create additional collection to keep this data, for example:
Meteor.UserInfo.user{friends, locations, previous orders, etc").
Thanks.
Use the Users collection to store information about that user that isn't related to other collections. Typically this should be at the top level of the user document, not inside the profile. The only thing I'd expect to see in the profile is profile information (and not, for instance, a list of previous orders).
Things like previous orders shouldn't be there since you can just query the Orders collection to find them. For performance reasons it is sometimes useful to denormalise this data, but this should be an exception, not the rule.