I'm trying to design database schema for a web app that serves as a dashboard.
There can be any number of Dashboards (User can create new dashboard)
Each Dashboard is associated with Teams (About 10-25 teams per dashboard)
Each Teams has Members (About 10 members per team)
Each Member has a name, role, email
Every Team submits weekly reports through a form (About 12 questions. All questions are same for every team except one question)
The Form responses are stored in the database.
Based on the weekly form responses, the warnings are displayed on the Dashboard (web app). There are fields like Teams issues, Number of meetings missed by a member, etc
What I've done so far
Is this the correct way to design the database? Can this be improved? I'm using Django to create the web app and SQLite3 database.
It looks like you are off to a good start. Based on your business rules that you listed, you might want expand your design based on #7. For example, you mention that team's attend meetings, yet there is no branch for this action by member.
One other area that I see for improvement is #5. Although at the start you may think there are at most 12 questions, your database model should be built to accommodate future requirements: your form responses should be composed from a minimum of four tables (Survey, Question, SurveyQuestion, SurveyResponse).
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.
My question has to do with the Salesforce integration in Social Tables and is two-fold: 1. Am I correct that only objects belonging to Contacts can be imported to Social Tables? 2. Is further integration under development?
To clarify, at present it appears that Social Tables pulls contacts from Campaigns, but does not pull other campaign data - only data stored in Contact records.
To really make use of the Salesforce integration, we'd like to import event data to Social Tables fields (e.g. Table #, Seat # etc). (Our use case is a seated fundraising breakfast.) Intuitively, that would mean Campaign Member in Salesforce would need to be imported to Social Tables along with Contacts (event-specific data can't be stored that in Contact records, since the guest data and data types would vary for different events).
Similarly, it would be great to have the option to import only the contacts in a campaign that have a specific status or "Attending?" value. I know it's possible to map Salesforce fields to event-specific fields in Social Tables, so maybe I'm missing something...thanks in advance!
Let me try to answer those for you.
Am I correct that only objects belonging to Contacts can be imported to Social Tables?
This is almost correct, for a given CampaignMember of a Campaign we are currently pulling all Lead or Contact fields (depending on the type of the CampaignMember). This does not include CampaignMember fields.
Is further integration under development?
My team is responsible for Check-In and although our focus is currently not on adding SF Integration features, we weigh customer feedback very heavily when revisiting our roadmap. You make a very valid point with including CampaignMember fields with the import and I will communicate this to our product team so they can handle accordingly.
Importing a subset of members is another great feature request that we will note. Once we have CampaignMember fields included you could accomplish this by importing all members then selecting users with unwanted statuses and deleting. Not the best but will work.
Thanks for reaching out with the fantastic feedback and hope this helps answer your questions!
We now have one site running but we will need to build a branded site for our client soon. The client site will have exactly the same data set as our current site expect for the user data. The client site must have totally separated user info which allows only the client to use the site.
I don't see the need for setting up a new database or creating a new user table for the client. My tentative solution is add a "Company" column for the user table so that I can differ which site the user data row is on.
I do not know if this approach will work or not or if it is the best practice. Could anyone with experience like this shed some light on this question?
Thanks,
Nigong
P.S. I use LAMP with AWS.
Using an extra column to store a company / entity id is a common approach for multitenant system. In general you will want to abstract the part that that verifies you can only retrieve data you're allowed to a piece that all queries go through, like your ORM. This will prevent people new to the project from exposing/using data that shouldn't be exposed/used.
We currently develop a portal in asp.net mvc2 with fluent nhibernate on amazon cloud servers which have lots of user which buying or selling shares. Also they comment every where and make other activities.
Portal is actually behave like multiple portals which we called Community. Our basic statistics based on users activity (buy,sell, comment etc). We have a basic structure called TopUsers. Which we show top user home page for all topics for loggedin community. On topic page we show top users for current topic etc.
Because of a lot of calculation I want to make a top users table. I am waiting for recommentations for this?
Your approach (separate table that gets periodically repopulated) is correct, except for the interval: your users will not be fanatically clicking on your site every minute to see updated stats, so after a certain threshold of data there isn't much point in refreshing your top users this often. Doing it once per day will usually be good enough.