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.
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'm working on a project using React 18 with Firebase Authentication and Realtime Database.
The project is a real-time chat between two users, I wan't this project to be very secure and protect messages/conversations. I have the following "cases" or "rules" to specify this chat functions:
User with profile Volunteer can chat with maximum 10 users with the simple-user profile.
Volunteer can see previous messages or the "history" with a registered simple-user but simple-user can't see previous messages. I need to protect chats for simple-user.
All the active "chats" between one volunteer and maximum 10 simple-users have to be seen just for the Volunteer profile. The simple-user just send and receive messages with a random Volunteer.
I search on the Internet which database fit better with my project model and Realtime Database looks like the better option. But now I would like to have your opinions about how can I handle the database to get the data and connection that I need according to the previous rules I wrote.
I know Firebase is a No-SQL database, but I create this diagram to know if the data structure for this chat could work.
If I store different information like the image above, could I get the information I need from each chat?
Turn is the working shift time that "volunteer" is working on the chat platform.
Session is the information of the turn of that volunteer and simple-users that they talk.
Chat is the "conversation" or the instance to generate messages between two different users.
My questions are:
Do I need a backend project such as nodejs? This backend would be for store the endpoints to firestore and apply some logic rules for queries this way I can have a React project without logic
If I structure my database like the image above, can I be able to get the information to achieve the "rules" that I need?
Do you have any suggestion to build a chat like this? In the future this project could be huge with a lot of data store and multiple users chatting with each other. Right now I have just the UI code and firebase connection. No other code yet.
Thanks for your contributions!
Okay so I’m need guidance on where to start.
What I want to do is upon clicking a button in my web app which will be labelled “search” the web app will connect to my realism database and search the data base for the “search criteria” and the once found all matching cases it will create div blocks with the information inside it, in a list view and assign the ID of the div to the UID it gets back from the database.
database:
Users
--> Country
---->State
----->City
------>Post/ZipCode
------->UID
--------> Users informantion
Welcome to StackOverflow!
A great place to get started is the Firebase Realtime Database doocumentation or searching for Firecasts on YouTube (linked below).
As requested, here are some questions to ask yourself to get started and help scope out and define your new Firebase project.
What language are you going to use?
Are you planning on using any frameworks/libraries? e.g. For Javascript, these would include things like jQuery, Polymer, and React
What information are you storing in your database? e.g. user profiles, private user data/settings, public indexes, username lists, etc.
How is your database structured?
What data is being searched? The entire database? Values in a certain location?
What data needs to be displayed in your view?
Is the data accessible for just the current user or is it a public database that anyone can use?
What search criteria will be used? Is it just one filter at a time or many?
The answers to these questions aren't set in stone, but are to help you start thinking about the future of your project. They can be changed at any time as this isn't SQL where everything has to have its own schema.
If you intend on using "advanced searches" where you'll filter by multiple parameters at the same time, consider using Cloud Firestore instead.
I recommend looking at some Firecasts to help guide you through these questions. Here are some links to them:
Firebase YouTube Channel
Video: Getting Started with the Firebase Realtime Database on the Web
Playlist: Firebase on the Web
I'm developing an app to help on events how much sales a single event has done and some other features that doesn't matter directly to the problem.
So, I've done an attempt to use Firestore to save my data, but something is saying to me that I was using the wrong way. Every event has something around 2k ~ (20k ~40k) entries of sales entries. Firebase Realtime Database doesn't seem a good idea because of data duplication needed for the relations I need to create.
The most important part of the Techstack I'm using:
React Native
React Native Firebase (native solution for react native on firebase)
Redux
The problem is that whenever I try to retrieve those documents for, let's say a custom report for my clients, the app just crashes or freezes entirely. Talking to other developers, they said to me that maybe Firestore is not a good solution for my case because of this 'sort of' big data retrieving.
Structure
Organizations/organization_id
Org_name
members (Array of userIds)
Events/event_id/
Event Name
Event sales data (Array)
Event product list (Array)
Event Date
Event attendees (Array of Attendees (name, pin (int))
Organization name
I've checked also that Firestore has a limit of 20k registries or entries per document (something like this). A friend of mine who have more experience told me that an SQL database an a normal API would probably solve the problem, but maybe require more work as I am a single developer.
Do you think that Firestore is a good solution and I was probably using the wrong way?
Or would say that Firestore is not the case for this problem where I would have to save and retrieve data with such relationships?
Im using Parse to save data from my social network. So far I have three class: Users, Posts, and Relationships. I want the user to be able to like a post.
Should I create a new table for Likes. If so, then on my storyboard page I would have to query through Relationships to get the user followers, then Posts to get the posts from the followers, and then Likes to get the likes from those posts?
Is it efficient to have three API requests to parse on one page. I feel like this will slow down performance but I'm not sure how else to save likes.
Another thing is, I would like to display a notifications tableView. So all likes and requested follows. So Im guessing I would save likes in Relationships and just query through it twice on the storyboard to first get followers, then likes. And on the notification page, have one class to query though once to get all recent notifications.
What are your suggestions?
Thanks.
This is sort of a broad question so there is no way that I could say for sure, but I do have a couple suggestion that you can do with parse.com.
Use the local datastore: You can save all of the likes that the user has in the local datastore as well as in the cloud of your application. So, for instance, you create the like when the user likes something, save it to the cloud, and then pin it to the local datastore. That way, you can efficiently query all of the likes that your user has created without using an API request. But in the event the user logs into the app somewhere else, you also have the likes in the cloud to retrieve. So, I would create a new table for likes.
You could use a join table to implement the followers, so, you could also pin the followers of the user to the local datastore like you would for a like. This is like is done in the Parse.com anypic tutorial.
I would also have another table for notifications. In cloud code, you could even update how many notifications the user has with an afterSave method, and then get all the notifications through a query when requested by the user.