I'm looking to do a very simple chatroom / messaging centre using stackmob but i'm unsure of the best way to use my schemas / relationships to ensure data permissions etc.
So far i have:
Schema - Chatroom:
fields - chatroom_id
sm_owner
createddate
lastmoddate
relationships - author - one to one - user
members - one to many - user
messages - one to many - message
permissions - read - allow to members relationship
Schema - Message
fields - message_id
message
createddate
lastmoddate
relationships - author - one to many - user
permissions - ?
My issue:
I would like to set the permissions of the message to only allow read access to the users who are classed as members in the chatroom that has the relationship with this message.
How can i know which chatroom is attached... the relationship is set on the chatroom not the message schema.
Is there another approach that I should take?
Thanks
Related
[user Database model][1]
https://www.linkedin.com/feed/update/urn:li:activity:6345250684744630272
here is my database design for user I want to add user_ following table in this scenario can anyone help me to build user_follower table scheme?
1- Each User has many other Users that followed him
2- Each User can follow many Users
So you have a many-to-many Unary relationship on User in your ER.
Now, to Mapping this data model to Tables: you can use a new table named: User_Followers and set 2 IDs of User as foreign key named source and target of following (and other attributes like date of follow and etc.)
you can find other mapping many-to-many Unary relationship (like Bit-Wise or Graph Data Models), but to your project, I offer as I mentioned.
In my database, I have a Customer table defined in my database that all other tables are foreign keyed on.
class Customer(models.Model):
...
class TableA(models.Model):
Customer = models.ForeignKey(Customer)
...
class TableB(models.Model):
Customer = models.ForeignKey(Customer)
...
I'm trying to implement a database router that determines the database to connect to based on the primary key of the Customer table. For instance, ids in the range 1 - 100 will connect to Database A, ids in the range 101 - 200 will connect to Database B.
I've read through the Django documentation on routers but I'm unsure if what I'm asking is possible. Specifically, the methods db_for_read(model, **hints) and db_for_write(model, **hints) work on the type of the object. This is useless for me as I need routing to be based on the contents of the instance of the object. The documentation further states that the only **hints provided at this moment are an instance object where applicable and in some cases no instance is provided at all. This doesn't inspire me with confidence as it does not explicitly state the cases when no instance is provided.
I'm essentially attempting to implement application level sharding of the database. Is this possible in Django?
Solve Chicken and egg
You'll have to solve the chicken and egg problem when saving a new Customer. You have to save to get an id, but you have to know the id to know where to save.
You can solve that by saving all Customers in DatabaseA first and then check the id and save it in the target db too. See Django multidb: write to multiple databases. If you do it consequently, you won't run into these problems. But make sure to pay attention to deleting Customers.
Then route using **hints
The routing problem that's left is pretty straight forward if an instance is in the hints. Either it is a Customer and you'll return 'DatabaseA' or it has a customer and you'll decide on its customer_id or customer.id.
Try and remember, there is no spoon.
When there is no instance in the hints, but it is a model from your app, raise an error, so you can change the code that created the Queryset. You should always provide hints, when they aren't added automatically.
What will really bake your cookie
If for most queries you have a know Customer, this is ok. But think about queries like TableA.objects.filter(customer__name__startswith='foo')
Is it better to create tables that store a lot of data that are related to an entity (User for example) or many tables to store said data?
For example:
User Table
Name
Email
Subscription Id
Email Notifications
Permissions
Or
User Table
Name
Email
Subscription Table
User ID
Subscription ID
Notification Table
User ID
Receives?
... etc
Please consider code in this as well, or I would have posted to ServerVault.
From a relational design standpoint what is important is the normal form you're aiming for. In general, if the "column" would require multiple values (subscription_id1, subscription_id2, etc) then it is a repeating group, and that would indicate to you that it needs to be moved to a related table. You've provided very general table and column notes, but taking a cue from the fact that you named "Email Notifications" and "Permissions" with plurals, I'm going to assume that those require related tables.
I have a University system project for my db lab.
I should have a unique login page for all the 3 user types: 1.student 2.Teacher 3.Supervisor
I already separated them in 3 tables(each has its unique properties).
My problems:
How to check when someone tries to log in?(which table should be checked and how to prevent duplicate usernames however they are in 3 different tables).
How to send messages between these 3 types although there is no central unique table to lookup(3 tables should be checked and there is a chance of username duplication)
My current ERD:
You should have all the users with their type in one table and additional information in separate tables.
you do not show any difference between the Students and the Professors in the schema.
also there is no 'supervisor' table.
i would suggest renaming the table to users - and adding a type or role column.
also:
the professors should be many to many with the courses also - assuming one professor can teach more than one course.
in the case where you combine the users, then there should also be a role on the association between users and courses identifying whether that user is a professor of that course, a student, an auditor, an associate, a substitute - etc.
I'm trying to design a wesite that would allow sports teams to more easily organize matches:
A user signs up and joins a team. Members can browse available teams and send them private messages to organize matches. After a match is done, teams can post comments on each other's pages mentioning their skill, sportsmanship etc. Here is what I imagined the database to look like:
User
* UserID
* Username
* email
Team
* TeamID
* TeamName
* OtherInfo
Review
* FromID
* ToID
* Date
* Comments
Message
* FromID
* ToID
* Content
UserTeam (junction table)
* pk (UserID, TeamID)
I'm not too sure how to model the reviews and the messages. A review has a from and a to field, so I can't just normalize the design like I would in a many-to-many situation, by using junction tables.
Note: Messages can be sent by either memebers and teams and can be received by either members or teams.
Not sure what the question is but if your messages (and reviews?) can be sent and received by teams or members, you need to differentiate the message purpose. Add a tinyint or some other column which indicates if a message is meant by a person/team to a person/team (so your query knows to use the FromID and ToID of the relevant table).
What about the team sizes and what do you mean by saying: "Members can browse available teams and send them private messages to organize matches."? Are all the teams the same size and can people skip from team to team freely? If so, you need to keep track of the team's members and if there are any need for additional members. You can do this in the Team table or UserTeam junction table.
I'm also guessing your website needs a login functionality. It might be a good idea to differentiate between basic team members and official representatives of the team. So only the official members (or whatever) are able to send (and receive!) messages between teams. (If you mean to implement a simple guestbook type of solution this point might be useless.)
Edit. An option for normalizing.
I don't see anything wrong in your current schema but you could combine Review and Message tables like this:
Communication
MsgID (PK)
FromID (FK to user, NOT NULL)
AnswerTo (FK to MsgID, NULL)
Timestamp
Review/Message (tinyint [what type the communication is], NOT NULL)
Text (NOT NULL)
Review/Message column could also differentiate messages between persons and teams, so FromID could be FK to TeamID as well.