I have a question about the best way to structure my Firebase database for my iOS app. The basic structure is that there are users and posts. The app will open and the user who is logged in will see all the posts that he/she has uploaded to the database (I may update this down the road so that users can see posts of users they follow). Is it better to have each post have a userId on it? Or is it better to have the an array of posts associated to each user?
If you can shard/partition the data so that you don't need to query a potentially very long list of that, that is always preferable with the realtime database.
So in your case, if you know that you want to show the user a list of their own posts as a starting point, it is a good idea to model that list in your database. You'd typically call this the user's feed or wall, depending on what your social network of choice is.
If you then later want to also show the posts of users they follow, you might want to store those posts in the user's wall. This type of data duplication may seem unnatural at first, but is quite common in NoSQL databases. In fact, this is the exact model that Firebase uses in its class FireFeed example.
To learn more about NoSQL data modeling, see:
NoSQL data modeling.
Firebase for SQL developers.
Getting to know Cloud Firestore, which is about Firebase's newer Firestore database, but has great tips that apply to the Realtime Database too.
Related
Looking for advice on my data structure in Firebase.
My app: Plant care reminders
I'm thinking the basic data structure can look something like this.
So the user can have many plants, and for each plant it can have many tasks.
I believe I would have a collection of users top level in Firestore, then each userData document would have a sub-collection of plants. Subsequently each plant would have a sub-collection of tasks.
The app will display all the users plants on one screen, that user can then click on a plant and view the tasks.
I would like the ability for the user to go offline for a period and still be able to access everything.
Is it wise to do one big query to retrieve all the data on the app load up? Doing this to make sure if they do go offline Firestore has all their cached sub-collections.
Or is it better to do a query on load up to get the users sub-collection of plants so they can see what they have, then when they click on a plant do another query to get that plants sub-collection of tasks?
If a user can see a plant, then goes offline and clicks that plant. Is it possible to query the plants sub-collection of tasks without network connection?
Apologies for poor explanation, trying to wrap my head round offline data persistence with Firestore and nested sub-collections when Firestore does shallow queries.
Firestore's disk persistence functions as a cache, maintaining data the app has recently loaded, and all local write operations that haven't been synchronized to the server yet.
I would like the ability for the user to go offline for a period and still be able to access everything.
This is inherently not a great match for how the Firestore disk cache works. To make it work in your use-case, you'd need to make sure to read all data, which will both drive up read operations and bandwidth consumption, and will also make the local cache runs more slowly than needed.
If you need a fully local database instead of a cache of recently read and locally modified data, Firestore might not be the best fit for this use-case. Consider using your own local database instead.
I have seen a firebase api in which you can create firebase projects and it occurred to me for example, when a user wants to counter a SaaS, make it easier for me to create a project and connect it to their SaaS but I have the following questions:
If there are supposed to be limits to creating firebase projects in a google account, will there be a time when databases can no longer be created for new users?
If the above is true, how can this be solved?
I have seen that you can ask for more projects, but how many can I have?
I know that with firestore, I can model data and only in a database have all the information, but for example, each user may have special requirements in their system and also provide security and information saving operations that would be impossible if all information is in a single database.
Thanks for the help.
EDIT
"How many projects can you have as a developer?" Yes, that's what I mean, having all the user bases in a single firebase google account. For example, on a web page, the user wants to pay for the application, with firebase admin and google cloud functions, I can automatically create a project and have all the databases in a google account. And what I want to know is if you can have multiple databases. I have seen that you can ask google to give you permission to host several projects but, for example, can you have more than 100 projects or even 1000? (I may never have reached that number, but in that case, I would like to know the limits that can be reached).
Edit 2
This first structure I have all the documents in a "universal" collection and I identify them with an id to know the user who used it.
But the second structure seems to me more organized and clean, in addition to the fact that users at no time need to share information among others. I have read that having nested collections is not good but over the years and the progress that firestore has had, this is no longer or was a problem only that the limitation is that you can only have up to 100 collections anidades but I never think to reach that quantity.
Inside of list, have all products for that user, because inside of document, only can have 1 mb of data and download 1 mb and is not the best option.
in the firestore documentation I see that it does not reveal other problems, it only says that it is difficult to delete the subcollection, but I do not allow users to do that and if I need to delete the subcollections, with the Google Cloud functions i can do it.
So, the second structure is more intuitive for me, but is the best option for that? or actually firestore is not good for this strcucutre?
I am building an application which uses SQFLITE(SQLITE) Database to save user's data by default.
I want that when users are logged in and online, this data is saved in Firebase, so that users can access their data from any device.
I have read that we'll have to create sync method to convert SFLITE's data to Firebase's NOSQL data. How exactly can I do this? Any useful links, examples, etc. would be really helpful.
P.S. I know Firebase has offline support, but it is not suited for my use case
I have referred on the below sites for getting ideas on better Firebase schema design for a social network application.
https://firebase.googleblog.com/2015/10/client-side-fan-out-for-data-consistency_73.html
Firebase fan-out structure for news feed
https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/
https://www.airpair.com/firebase/posts/structuring-your-firebase-data
But I fail to understand the recent developments and features available in Cloud FireStore of Firebase.
I have below requirements to be store.
To Store Image Upload
Comments for the Image
Likes activity
User following activity
I should be able to get them individually or all activities in a single call. How best can I organize the data model?
All the above is present in the below example. But I have question on getting all types of activities to show the master news feed in a single call sorted by time.
https://github.com/firebase/friendlypix/blob/master/design.md
PS: I will be using it with Flutter.
Other models discussed: Firestore - how to structure a feed and follow system
This Udemy course gives a very good idea about how to design a fanned-out social media DB. However, it doesn't implement the "fanoutObject" concept mentioned in this blog. It is updating each duplicate collections independently. So not sure how consistency is guaranteed.
I'm planning a web application that requires user auth, plus the ability to display data for the users that is stored in a database. No interaction between the users is needed (yet), however the users should be able create objects and query their "own" objects. For example I list 10 book names (10 book objects), and User A should be able to pick a book and create a new object, call it userNoteObject that contains the name of a choosen book and a short note (that he/she writes).
With a basic pseudo code one book object would look like this:
bookObj = {"id": 1, "name": "book name"}
And the user's note object would be something like this:
userNoteObject = {
"id": 1,
"book_name": "random book name",
"owner_userid": "a1b2c3d",
"note": "some random string"
}
With MySQL I would create three tables, one for the users and one for the userNoteObject-s and another for the bookObj-s. Everytime an user saves a note, I would add it to the table that lists the saved notes. Then I can simply query the notes that belongs to X user based on the user's owner_userid. It's a quite simple functionality.
After reading about the possibilities I've made a decision to go with Firebase Auth (because in the future I might need Android and iOS compatibility) + Google Cloud Datastore or Firebase Realtime Database. However I'm a little bit scared about the Realtime Database of Firebase since I've never worked any DB like it. I also like to be able to modify records manually with something like PhpMyAdmin and I assume Cloud Datastore has a visual interface like that.
I'm familiar with JSON handling and creating JSON files, however the JSON based database is strange for me at the moment. Therefore I'm thinking about that maybe the other option would be a better choice. It's very important that I don't need realtime db features. I would load X number of entries into the table that holds the bookObj-s and sometimes update them. I assume when the user creates an userNoteObject it would be saved quickly with both and after deleting an userNoteObject I could refresh the page close to realtime with Datastore. But the table that holds the book objects must be able to store millions of entries easily.
So the important things:
One db table should be able to handle millions of records easily
Easy as possible querying
Visual interface for the DB (if it's possible)
I don't need realtime features like dynamic game score display/saving
Other info:
I would like to use Angular.js
I'm familiar with Python if it can help in something
So my question is that which database would be better for my needs? At the moment I say Datastore, but I'm totally new with these services so I'm not really against the Realtime Database, but Datastore looks more suitable since it has a visual interface. However I'm also not sure that how would work Datastore with Firebase. If there is a third option like combining both, Realtime Database for the objects save by the user and the static objects for Datastore for example, I would love to hear about it too. My overall goal is to be able to write and query the db easy and fast as it's possible and easily use it with Firebase auth.
UPDATE: I just discovered Firebase's Cloud Firestore, so if it can be more useful I could use it.
If you are going to use Firebase I would recommend you use Cloud Firestore instead of either Cloud Datastore or Firebase realtime database. You get the benefits of a real-time database plus a true document based JSON data store. The one downside is that you don`t have a UI to interact with the data. Datastore has one but its not as robust as say PHPMyAdmin. And since these are NoSQL datastores SQL support is pretty limited.
If you really want a true relational back-end you could try Cloud SQL which is basically MySQL running on Google Servers.
For the Firestore console/UI, see https://firebase.google.com/docs/firestore/using-console. Is that the kind of thing you're looking for?