I am planning a mobile application to use Firebase as its database/authentication provider mainly because I have found the authentication really easy to implement and also because of the apps nature. The app itself revolves around users in groups. Within each group is a range of data that will be accessible by every user in that group.
I am wanting some feedback on my proposed firebase database structure and if there is anything I should do differently or could do better.
Current proposed structure:
{
"users": {
"userID": {
"userName": ...
"email": ...
"group": groupID
"creationTime": ...
}
},
"groups": {
"groupID": {
"name": ...
"members": {
"userID": true
"userID": true
}
}
},
"lists": {
"groupID": {
"name": ...
"items": {
"itemID": true
"itemID": true
}
}
},
"items": {
"itemID": {
"name": ...
"createdBy": userID
"timeCreated": ...
}
}
}
Here are a few things I want to clarify:
Is it wise to seperate lists and groups or should I embed the items within each list object?
Am I okay using groupID as the identifier for both the groups and lists seeing as there will only be one list linked to each group? This was means I can easily access this list from the users "group" variable.
The Firebase Database documentation recommends keeping your data flat, not nesting unrelated types of data. It seems you're trying to do that, so that sounds good.
If you flatten your data, you will need to have a way to relate items in the various lists with each other. The simplest way to do that is by giving the corresponding items the same key in all lists. They're like PK/FK in a relational database, except that Firebase (unlike most relational DBMSs) doesn't manage the relation for you.
The topic of data modeling is incredibly broad and it's hard to do it justice in a Q&A format. I highly recommend reading NoSQL data modeling and viewing our Firebase for SQL developers series. You'll also find a lot of data modeling questions in this list.
Sorry I can't post a comment. I would recommend to make your life easier to have the same ID each of the data. Also, look into userIDs and PushID, they might come handy.
To get push id you can:
and you get userID:
Have something like this:
Think of userID as your primary key and pushID and unique identifier. There can be one user (uID) who can have many data under them (pushID)