I am creating site and there are 3 roles on it. Administrator, Teacher, Parent. User with any role has access to site, but 1 role has full access, teachers can only put marks for students, parents can only watch these marks.
I understand how to separate roles into scripts. Just save some parameter depending on what database would return when I check login and password.
So! Administrator has only login name and username. Also it is possible to store information about how to contact the user to make system more user-friendly. That's all.
Teacher has firstname, lastname, midname (father's name), address, phone etc. And it must have login and password fields...
Parent has Firstname, Lastname, Midname only. And sure somewhere I should to store data about login and password.
So should I just check this tables 1 by 1 and depending on table I will find $login and $password I inputted in I will return role? I don't think it is a nice idea. Suggest something else please.
What I think to do. I think that it would be not very bad idea if I will create 1 more table like users where I will store: id, username, login, role, user_id (need to think about it). The problem is user_id. How exactly this table will be connected to others? For example user_id` would be 1. 101% there would be 1 row with such id.
I want to ask about exprience of your self-build systems. May you suggest something please!
You're right. It doesn't make sense to have different tables for users. I would recommend you to store authorization and personal data in separate tables. And of course you'll need additional table for roles:
The idea behind this scheme is to keep thin users table for fast authorization. If authorization was successful, than you should check permissions from roles or get personal data from user_data tables.
Look at this sql-fiddle for DDL.
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.
First lets start off with I am writing a program in VB.net and have a database set up and everything works fine as of now. The program is user based and requires the user to log into the program and it will show them all of there user information, orders, settings, fees etc, etc... and everything that is needed. The issue I have is right now I have each user set up with a different database. I have the user login and connect to a database that just holds the Users and initial program start up settings. Along with this it loads the users database address and password into the program so I can then access there database and pull from all the tables relating to them.
I feel that having a database for each user is a bit overboard but each database pertains to the specific person and the information can be sensitive including address, amount of money made, and many other things so I don't know how to set it up to be most productive because if i have 50 users I don't want to create 50 databases.
Please help with this. Even if you just point me to several places to read and learn I would love that.
Thank you in advance.
Creating seprate db for each user is not a way to go. You have create a new user table in 1 db and add userid in your ref tables. Below is an example how to achieve this
User - Userid, UserName, Pwd etc.
Address - Userid, Addressid, HouseNum, StreetName, City etc.
Shipping details - Userid, Shippingid, Shippingdate etc.
In all your queries based on Userid pull data specific to the logged in user.
Also you should always connect to your db using some service account from your application. Validate if user is authenticated or not using some stored proc or query.
I'm having a bit of trouble figuring out how to structure my database for an application I'm building.
There will be three different types of users:
Admin
Applicants
Reviewers
I'm planning on having a general users table to store shared information between each user type. However, I'll need to store quite a bit of information for Applicants that I won't for Reviewers, or Admins, and I'll need to store some permissions information for Reviewers that I won't for Applicants.
I know I'll need to set up some additional tables to accommodate this information but I'm not sure how to do so. Should my users table have an admin_data, reviewer_data, applic_data fields as FKs? How would I detect what type of a user a person is when they login?
Each user will only need to be one type.
Thank you for your help.
Have an accounts table with login info, account id and account type. Then join to the appropriate related table (admin, reviewer, etc) to get relevant info.
There's no reason to mix the data since it sounds like it varies quite a bit.
I am working on one portal where will be few user roles. I have been wondering what is the best way to handle them. I have created separated tables for users and clients, but clients will want the functionality as users and users can become clients easy too.
I also don't want to make many joints, so what I as thinking is this:
I will have 4 different user roles (at least for now) as follow:
user
client
reviewer
admin
I will assing "id" to each role. At the same time I will keep table in mysql with these roles. It will be something like:
1 - admin
2 - reviewer
3 - client
4 - user
This table will be used only upon creation of user, to get the code of user "permissions". So Let's say that there will be a guy who is a user and reviewer. His role would be 24.
login password email role created
----------------------------------------------------------
guy password guy#gmail.com 24 2012-12-08 23:12:30
I think this could work pretty well, but still want to ask if you guys think this is good and effective solution.
Thanks
The other way to do this would be to have a many to many USER_ROLE table where for your example guy would have the following entires.
login role
guy 2
guy 4
I generally prefer this method of tracking roles. A join against this table in a situation like this should be fast and painless, especially if you move to using a user_id instead of a login, and index appropriately.
What you're defining is a Role Based Access Control System (I would suggest looking up resources on this). An RBAC system will have a separate table for users and another table for roles. There will be a many to many relationship between users and roles. Also, you will connect a permissions table to roles in another many to many relationship. The image attached represents how to implement this system:RBAC SYSTEM IN MYSQL
A similar question was asked before: How to design a hierarchical role based access control system
Here is the situation:
I have a "user" , which have many attributes. For example, "name", "email", "password", "phone".
There are some attributes that are open for public, for example, "name", "email".
These information is open for evenbody who visit the site.
But some, only for trust body in the system, for example "phone".
These information is open for the people that the user trust.... (Assume the user have a trust list that can accept other user to the trust list.)
And the private one "password".
This information is only for the user only, other people can't get access to it.
User can change different security level based on their need, for example, the user want to change the "email" for only trusted body, they can do so. It is also allow the user change their "phone" to public.
I use three number to represent three level of right. The first one with 3, second is 2, and the private is 1. So, I design the database in this way:
User
id(PK)
nameId(FK)
emailId(FK)
passwordId(FK)
phoneId(FK)
Name:
id(PK)
name(String)
securityLevel(int)
Email:
id(PK)
email(String)
securityLevel(int)
Phone:
id(PK)
phone(int)
securityLevel(int)
Password:
id(PK)
password(String)
securityLevel(int) //It must be 1
The question is, I can do it but my database will have many table, is there any simple way to do it? Moreover, is there any books about these kind of database design is recommended? thank you.
You don't need different tables for this, because each relation is a 1-1 relation.
Should a user have, say, multiple e-mail adresses, then you indeed should put the email and securitylevels in different tables. But because in this case, each user has exactly 1 email, 1 name, 1 phone, 1 password - just one table with 1 row per user should do.
If I understand this correctly, you could simply put all this information in two tables (user and friends) because as far as I know, it is a lot more efficient to get larger chunks of data with few queries, than smaller chunks of data with many queries. You would have something like this:
Users:
id
name
name_perm // 1, 2 or 3
email
email_perm // 1, 2 or 3
phone
phone_perm // 1, 2 or 3
password // Doesn't need permissions, always 1
Friends:
user_id
friend_id
When a user visits another user's page, first you check the permission level for each field. If level 2 is found, you would then query the friends table and check if current user ID is a friend of the user whose page is being viewed. If found, user is trusted and level 2 security info can be displayed. As for level 1 security, it's really simple - only display this info if both IDs match.
Hope this helps.
Whether or not the private data is segregated into a separate table does not solve the issue of how to prevent unauthorized access. The MySQL 5.1 manual section 5.4.5 discusses request verification/privileges, but if your database is hidden behind a web application with no direct access to your tables, then standard web server security alone might be sufficient. You should probably mention the entire os/server/db/language bundle you're using (LAMP, SAMP, whatever) so someone can suggest the best security scheme for your configuration.