I'm building a React/Firebase app, and I need to structure my data so that many users can use the app with proper performance and security.
Here's the outline:
I've got the standard firebase users (for authentication), and an extra users collection to store extra data about each user (address, etc).
Every user should have has a bunch of tasks, only accessible/viewable by the user himself. Tasks cannot be shared between users.
Besides tasks, there can be many other types of documents that are user-specific. For instance, projects. Different projects can contain the same tasks, but the projects are user-specific.
Should I store all tasks in a tasks collection, all projects in a projects collection, then referencing which user the task/projects belongs to in every task/project document? In such case, do I simply store the uid of each user in the document?
Or should I have a collection tasks, a collection projects, with a sub-collection for each user?
The main concerns are performance and security, I have no idea how firestore compares to classic relational databases as far as performance goes.
Related
I am having one problem while working on Mongo db with an Node js project,
I am creating a Meeting Scheduler project where a user(admin) can create an account and register his company on our project and that company has 1000 members and few teams and members can be a part of multiple teams and some members can be alone not in any team
and their are multiple admins with different access
and their is also an data of meetings
Their are Personal meetings of a member with one or multiple members
and also their are Team meetings
Their is also an data of messages
A user can send the message to his Team
Their is also an TODO list of the particulars Teams
So what I tried is storing data in the only one User Model where it has every data about his Team, Personal and Team Meetings and Team Messages I have to store in every User's Collection
The issue in this is that its I know its not at all the Best and Optimized approach to solve this problem and this will consume a lot of memory
Can Anyone please suggest the best way to Store this data like how to store data in different Models/Schemas and how to link them for the best performace and ease to access and perform CRUD operations
I need help understanding the best approach to structure my firestore data.
I come from traditional SQL background and have a little bit of nosql mongodb background as well. I am building a small football prediction app and here is the user flow:
User:
User registers/signs in
They can pick a contest to join
Enter their predictions every week
Admin:
Create contests and add/edit games to contest every week (an api will fetch all the data like fixtures and results)
Set a deadline for when users can enter their last prediction for the game week
Other:
Leaderboard
Now I did create a diagram on how I would traditionally structure this data but it would be nice if someone can exaplain to me the simplest approach to structuring such an app in Firestore
It looks reasonable but I would be concerned about storing the passwords in Firestore DB. Firestore should not ideally be concerned with authentication. Check Firebase Authentication for different auth options with Firebase. You'll probably end up only having to store the user ID as other information is in the User object.
Also check out Supported data types. You probably want to change varchar(x) to (UTF-8) string or byte types. Moreover, there is a reference type so you could reference the actual user document from the other tables.
One main design will be whether to use nested collections (Hierarchical Data).
You might be able to nest score under competitions.
I have an app where users can follow each other and I currently have a database structure which allows users to follow, unfollow and see their followers/following users, and see the number of followers/following they have.
The way I have structured my database is by having a users document stored in a usernames collections which contains their followers/following count, and all their info. Like profile image and display name etc.
Then, this users followers/following users are stored in a subcollection as a document. In this document, there is a document reference which points back to the root usernames collection, and to the following/followers users document, where i then pull their info if needed.
I was just wandering if there is a more efficient way to structure my database. This seems like the best option but I have a feeling their is an even better way which i am not thinking of.
Thank you
I'm building an application with AWS Amplify, where I have three DynamoDB tables: Users, Posts and Subscriptions.
users can make posts
users subscribe to other users
user A can only see posts by user B if user A is subscribed to user B
Points 1. and 2. are easy to implement with standard graphQL mutations. But I'm stuck at how to implement 3. in an elegant way. Currently what I do is to use a lambda resolver.
Given inputs "user A wants to see user B", the lambda resolver does the following:
Query Subscriptions table to see if there's a document for "user A subscribed to user B"
if such a row exists, query Posts table and return documents. If not, return nothing.
This logic required two round trips, but since dynamo is fast I'm OK with this trade-off. There are other downsides though, so I'm wondering if there's a more Amplify-native way to do this? Some magic DynamoDB and #auth trickery perhaps?
Thank you!
If you are using multiple tables to store the data, the multiple query approach is your only option.
You can use transactions when mutating items across multiple tables, which is useful when you want to perform an operation based on a condition on an item in another table(s). But when it comes to a read operation, you have no such option.
Aside from re-designing your tables to support this access pattern, I don't think two reads is particularly bad.
If you wanted to handle authorization logic outside of DDB, you may want to look into AWS IAM and it's documentation on Fine-Grained Access Control. Among other features, IAM can restrict access to specific items in a table based on certain primary key values.
We have a SL application and many users who use this system with different data and access roles. For example, each user can have some devices and each device will send its locations every 5 minutes to server.
One approach is defining a User table in database and have many tables which connect an entity to a user Id, but this is not a good idea as that creates many tables between users and other entities.
It will be a time consuming process to select user data or reporting, so I wanted to know what the best way is for handling such behavior in Silverlight?
You can use AuthenticationDomainService. This is a popular service for authorization users with roles. You can get more information there: http://msdn.microsoft.com/en-us/library/ee707361(v=VS.91).aspx