Hi currently i have 3 tables:
users
|id|name|email|password|last_login|created_at|
user_groups
|user_id|group_id
groups
|group_id|name|email|password|last_login|created_at|
Group can login so it when i can view statistics for specific all it users, that's why i put email and password too.
the problem is users and groups got almost everything same. 1 group can contain many users.
Is there anyway to make this more normalize and user still have their specific groups?
I would just use the user authentication to detect whether the user belongs to any group or not. That way you don't need all these extra fields for the group.
If you only want one specific user to be able to look at the group statistics you could add an admin_id to the user_groups table (which would relate to a user id)
Related
I am using PHP , MySQL for Handling My site. I have a user table called user_table containing user_id PRIMARY and Now user can chat with other user. For that I am using a table called message_table. this table contains essential fields like msg_id , sender_id , reciver_id , replay_id etc. this works very fine.But I need to handle also guest users[Not registered] with this chat. how can I handle them. I inserted the guset_id as the mixture of entering time and his name to a table called guest_table. Now I can use this guest_table like user_table. Is that a good idea ?
But I need to handle also guest users[Not registered] with this chat.
These guests look to me like a special sort of user. I suggest you handle them as if they were users. You may wish to put a column called something like is_guest in your user table, and set it to 1 when you know the user is a guest.
Keeping a separate table, parallel to the user table, for your guests is NOT a good idea. It will greatly complicate your queries, especially when a person in your user table communicates with a person in your guest table.
Instead, put everybody in the user table, guests and registered users alike.
A nice little benefit: if you convert a guest to a registered user, all you have to do is flip the is_guest flag and let them specify their own username and other data. They get to keep their history.
Background: I am new to Rails and I have gone through Michael Hartl Ruby on Rails tutorial.
I have read Agile Web Development with Rails 5.
So for practice I was trying to design WhatsApp like framework and got stuck while creating User and Group model.
Problem: I have tried different user and group model relationship and each one is failing for some reason.I have tried few paths so I will enlist them below.I don't need code, just a correct database relationship between User,Admin,Group,Participants.Also we should be able to add relationship through UI.
We have two tables User and Group.Admin belongs_to Group.Group has_many Admins. Group has_many partcipants. Participant belongs_to group.Participant is a new table having user_id and group_id.
We have three tables User,Group and Admin_Participant.Admin_Participant table contains admin_of column and participant_of column and one user_id column.admin_of and participant_of will contain group_ids.
Similar to first but we have a different table for admin which contains user_id , group_id, boolean table for is_admin.
Group is reference to User and admin column is boolean.Participant is added to User table and is also a boolean.
One more Thing As soon as a user creates group he is assigned to be admin of that group.Remember the restrictions of participants.
3 tables ( and their models ) should suffice.
User
has many participants
has many groups through participants
Group
attribute: created_by ( user id )
has many participants
has many users through participant
Participant
belongs to group
belongs to user
attribute admin
The above should work provided that an admin is also a participant.
If there are admins who are not participants, then a extra column for 'participating', or 'non-participant' is required.
There is no need for an admin table unless the admin has other attributes.
In case you haven't, it's good to go through the guide
So this might be too far down the rabbit hole but I see only 2 tables, User and Groups. A user can be a admin and/or participant. The relationship between user and group would probably be has_or_belongs_to_many as a user can belong to many groups and a group can have many users. Further, to accomplish the user/admin/participant distinction, I might even subclass it with STI(single table inheritance) instead of using booleans to determine if someone is an admin or not.
as you specified you need a relationship model not code.
i think i can help.
you might have to reshape your whole database, but if i were you, i would do it like ...
User - name , user_id , mob_no , groups (before someone need to log in , my app would send em the code through which they can verify that they are the owner of that mob no. //we would not discuss that in detail/// )
######## has_many: groups
group - name , users , admin(boolean) (i made a different column for admin, the users column stores the user_id of the user , when someone creates a group he automatically becomes the admin , so admin column becomes true for that user id.. and later that admin can make other admin as well...[if you have problem implementing this i would suggest opening up michael hartl's book and read how he made an example user an admin and that admin could delete other users , that will help])
########## belongs_to: user
i do not understand how you would implement the admin of a group to add users to group,
so in this case i would like to suggest the following -
$ if the user has followed another user he can add that user to the group...
$ or a facebook like system " where user gets users invite to the group ,and later its upon him to decide whether he want to join or not.
% pls comment and lemme know if this helps. and any other suggestion.
I'm developing an e-commerce site and I wanted to get this community's thoughts on a database structure for groups, users, and their memberships.
THE GOAL: Determine a user's group membership(s) and access privilege at login. A user could be a seller on this site, an admin, a site support, or ANYTHING. Must be scalable.
INITIAL THOUGHT: Three separate tables: users, groups, and memberships. At a successful login, search the membership table for the user's ID and get group ID's from that same row in the membership table. From there, another query to get group information from the groups table (like name of group, description, etc). Store the memberships in the user's session and call it a day.
THE CONCERN: At log in, I don't want to unnecessarily perform additional queries. The above "initial thought" consists of 3 separate queries at login.
THE QUESTIONS:
Is this the right approach?
Any better design solution(s)?
Better to break admins into their own table, or toss 'em into the same groups table?
The database design is reasonable. As a user can belong to multiple groups and can have multiple memberships, two additional tables USER_GROUP and USER_MEMBERSHIPto hold the relations between users and groups and between users and memberships will be necessary.
I have a user table which has all details like username, email id, birth date, contact no. A user has friends and these friends may belong to certain groups like for e.g close friends, family, colleagues which user has created. A friend may belong to one group or many groups or none of the groups at all.
I need to set a certain privacy related to the attributes of the user table for friends or group of friends. Like for e.g. my group of family can only view my birth date or colleagues can view only my email id but no other details like birth date or contact number.
How can I achieve this privacy?
Thanks.
Having a separate table for every "special" attribute, could lead you to have a lot of tables. On the other hand, you can use the entity-attribute-value model. This way you will have one table for users, one table for all the user's attributes, and one table for the values associated to an specific user and his attributes.
User
id
idGroup
Attribute
id
description
Value (User-Atribute)
idUser
idAttribute
value
In addition, you can relate the attribute table and the group table. By relating these two tables you can specify which attributes will be visible for each group. Don't forget to relate the user table and the group table.
Group
id
description
Access (Group-Attribute)
idGroup
idAttribute
Shouldn't you try to handle that logic on the code, instead of the database? It seems that this is related to business logic instead of the actual data model.
If you want to go forward with this approach have you considered having the private data in a separate table?
I have 3 user roles, ADMIN, GURDIAN, STUDENT. I have the GurdianProfile & StudentProfile tables linked using uniqueID's (i.e. GurdianID, StudentID). That is the link that connects the 'gurdianLogin' tables and 'studentLogin' tables.
My Question is: What is the standard way to structure a 'User Login' table? Should I use one single table to store different types of users (i.e. all the 3 types of users) ? Or is it better to use 3 different tables to use different type of users on a single database ?
What is the best-practice and strategy or recommendations ?
Note: I'm using ColdFusion, MySQL
If you have a single logon point, I would see having credentials spread across 3 different tables as a flaw because if you ever added a 4th user type, you would then have to update your login system to incorporate the new user type. So, i would go with having a single user table, and then if you need separate tables for your guardian/student/admin profiles, link them to the user table.
_User_
id
email
username
password (this better not store the password in plain text..)
_GuardianProfile_
id
userid (links to user table)
(GuardianProfile fields)
_StudentProfile_
id
userid (links to user table)
(StudentProfile fields)
_AdminProfile_
id
userid (links to user table)
(AdminProfile fields)
If the columns in the three profile types are the same, it might make sense to condense that to one table with a type column.
I use one table to store login details - userid (primary key), salt, passwords, usernames, email addresses.
I authenticate against this table. I then use other tables linked by the userid to store contact information or other important data.
For restricting access to certain parts of the site I create other tables such as user, adimn, superadmin and store the userid's. I then test against the desired table to see if the userid is present and thus determine access to a page/area.