Let's say you have students
and you have teachers
Students log in to the site using a different interface than teachers
Students can do the following on the site
- Look up grades
- Email teachers
Teachers can do the following on the site
- Lookup up students
- Input grades
How would you design the database table to allow teachers and students to log in? This question confuses me because I was thinking of doing the following
of having a teacher table
of having a student table
two separate tables
so
create table teacher
(
name varchar(255),
email varchar(100),
password varchar(100)
)
create table student
(
name varchar(255),
email varchar(100),
password varchar(100)
)
Is that how it is usually done? When you have two different entities logging in to two different login interfaces?
--- EDIT ---
also what if the two entities have different fields? Would you still create one Users table with a "Role" in that case.
For example, what if you have the following:
(notice how teacher and student have a few fields different. Would you still create one table to put them both??)
create table teacher
(
name varchar(255),
email varchar(100),
password varchar(100)
num_of_students int,
)
create table student
(
name varchar(255),
email varchar(100),
password varchar(100),
gpa decimal(10,2)
)
I would consider just making it one table and add a TypeID, where TypeID would classify the type of person be it a student or a teacher.
Take a look at the design of both of those tables, they are exactly the same, this should be a signal to you that you may be overdoing things.
By keeping it in 2 separate tables, it is more UI work for you and more administrative work for the person entering the data.
By combining it into one table and introducing a classification or type field you eliminate all that extra work.
CREATE TABLE Users ( ID int, Type int, name varchar(255), email varchar(100))
I also would not store the password as plain text, as it appears you may be hinting at with password varchar(100). Type in this case could be an int or even a bit datatype if the only two types of personnel will be Students and Teachers. The field could be IsTeacher with 1 being a teacher and 0 being a student. But in most cases, you end up realizing you needed a different type of User, hence the int datatype.
Designs in most other answers here lack when a user have to be assigned with two "types" or more. In fact, the question is very obviously about users associated with roles which are thenselves associated with rights. And therefore a typical table layout for role-based security is the best in my opinion.
Entities and Relationship
User: John Q. Public, ...
Role: Teacher, Student, ...
Right: Look up grades, Input grades, Look up students, ...
You've N:M relationship between each:
User<->Role
Role<->Right (optional)
User<->Right (optional)
Maybe checking for roles is enough and you can drop anything with Rights here.
Solution
Just have a User table. (Table: User)
Teacher and Student are Roles which Users can be associated with. (Tables: Role and User_Role)
Another Role you typically have in every application is the Role Admin which for instance can delete other users, reset passwords, create new users ...
When you've complex rights then you can add Right, too. Right can be both associated with User as well as with Role.
I would have a single login table of an ID, email, password as you have, but tack on a flag for TYPE of login... Admin (Site wide), Teacher, Student, whatever.
Then, from the login, you'll have that "type" as a flag to show/hide elments within the site or offer other redirection as needed.
I would make one table - person and add field type to it. Type can be STUDENT or TEACHER for example.
What I would do is have a single table called lets say 'users', then a column called 'role' for example, I would then create a script in each interface that will only allow students to login the student interface and teachers in the teachers interface.
To be honest I would actually only have a single permission based user interface, but that is what I would do if I were to use 2 interfaces.
I hope this helps you.
Related
Here i do the Login Validation
$LoginData = Input::except(array('_token')) ;
if(Auth::attempt($LoginData))
{
return 'success';
}
My Table is different so, here i change the table name in auth.php
'table' => 'administrators'
But I have the dropdown to choose for the usertype.
So how can i choose the tables for Authentication according to the usertypeinput.
i.e., Table may be administrators or parents or employees
I don't know whether Laravel supports the change of auth table name on fly or not. I can suggest you a quick solution.
According to generalization theory of database design, you should store same type of information to one entity set. And according to specialization theory, if entity set can have various types of information for each entity, break them down into sub entity sets.
Suggestion:
Create user_types table with column id & name (store user type names here)
Create table users with 4 columns id, email/username, password & user_type_id (user_type_id is foreign key references id of user_types)
Create 3 separate tables named administrators, parents or employees. All 3 tables should have one column user_id which is a foreign key references users table.
Create relationship in model
After a user login, you can determine which type of user he/she is from the user<->user_type relation
You can get rid of the usertype dropdown from login page view now (You were disclosing some important information (3 user types) about your application to the whole planet, isn't it harmful for your application?)
More info about generalization & specialization:
Generalization, Specialization and Aggregation
I want to create 3 tables: boss and employe inheriting the table person.
person: id, login, password;
boss: id, login, mdp, firstname, lastname, email;
employe: id, login, mdp, firstname, lastname, email;
I separate those two types of persons for control the rights.
But I want to keep a table that contains all users to manage a connection.
The problem is the auto indentation in the three Ids. When I create a member of type "boss", the ids in the tables boss and "person" are auto identated at 1. And when I create a new member of type employe, The ids (1 in "employe" and 2 in "personn" beacause the first is the boss) are not the same.
How I can modelize it?
Thanks and sorry for my English, Florian.
You have a lot of duplicate data being stored. Consider this alternative:
person
------
id
login
password
firstname
lastname
email
boss
----
id
person_id
employee
--------
id
person_id
I can store the exact same information using this structure as you can in yours, but each 'person' will only have a single firstname/lastname, email address, login and password. You should only store in the boss / employee tables information that is relevant to only that entity. A boss for instance might have a security_code field whereas a regular employee wouldn't.
You shouldn't try to keep id primary keys between two different tables to match up (i.e., boss id doesn't need to match person id). Instead, add the person_id foreign key so that if you have a boss record you can easily lookup their information in the person table from that.
I want to design a DB which will be connected to PHP Application. In the app there are two types of users: company and person. Some functionality like adding articles will be done by both so in other tables there are author_id columns. So firstly I decided to create user column.
That's easy: id, username, password, role, active, created where role defines whether user is person or company.
Now I want to add profile table or profile tables depends on what you'd suggest (joined with the previous table by adding profile_id column there).
Both roles have different fields, which are required during registration.
The easiest thing would be to create one table with all required fields for both roles, allow them NULL values and in the PHP app (made in Yii Framework in this case) define requirements for each role in models.
The nicest thing would be to create separate tables for both roles BUT the questions is how to connect these two tables to one table using Foreign Key? Is it even possible. I know I may omit foreign key creation then based on role choose table, and from that table choose profile_id.
Or maybe you have another solution to my problem.
Thanks in advance for replies.
Adrian
You need an intermediary between the page and the database to assign the user to a group that has specific privileges. It's usually accomplished with a user-group-role design.
You can have a table for users system info (username , pass ...), and another for users profile (firstname , birthday ...), and another for groups(superuser , ...).
where user table can have multiple groups: user:one->group:many
user can have one profile user:one->profile:one
I think this is a decent solution.
Here is what I want to ask:
I want to make a system to register patients so then they will be able to login. I have 3 type of users though.
admin (no need for registration)
doctor (standard number of doctors, no need for registration)
patient (they will be registered)
I want to keep more info for them than just id, username, password, email.
I am thinking of having more than 1 tables to do this and link them with primary and foreign keys:
1st table
accounts (it will store the login data)
Example:
acc_id(primary key)
acc_password
acc_username
acc_type
2nd table
doctors_extra_info
Example:
acc_id (foreign key)
doc_info_id (primary key)
doc_name
...
...
3rd table
patients_extra_info
Example:
acc_id (foreign key)
pat_info_id (primary key)
pat_name
...
...
4th table
admin_info
Example:
acc_id (foreign key)
admin_id (primary key)
admin_email
a. Which is the best way of doing this?
b. In the part of
registration, how to deal with primary and foreign keys? Two insert
commands in two different tables? [In order to have the same acc_id
in the account table and the extra info table]
c. At the login part,
I need to check the type of user and redirect (header(Location: ..);)
to a page? Is this the right way of doing it?
Any suggestions?
Thank you.
If you're using PHP then when you insert a record you can instantly retrieve the ID created using mysql_insert_id(). You then use this to create other records as your foreign key.
With regards to redirects, I'd simply get the user type from the database and then check the type of user and redirect to page required.
Generally though the tables you have created do not correlate properly. Remember the defining thing about the people using the system is that they are a person, and shouldn't be deined by their job role. They should have a account_type_id linking to another table. Otherwise you have three tables essentially holding the same information.
For example you should have your tables like this
User table
user_id
first_name
last_name
email
account_type_id*
Accounts type table
user_id
account_type_id*
account_type //e.g. patient, doctor, admin etc
This means now that you can easily extend the database with new tables, user access levels, new columns without having to duplicate the same column across three tables and so on. Try reading up on database normalization. A very good video from youtube is http://www.youtube.com/watch?v=fg7r3DgS3rA
i want my database to support one company haveing many users how can i do that? exampleusers table(UID,username,password)company table(CID,companyname,usersthatistheownerofthecompany) how can i do that? what should i do ? should i make an array in php like 1241,423,4123 *uid's that will be inserted on usersthatistheownerofthecompany row ? or is there any better idea ?
If you want each user to have one (and never more) company, you should have :
user table
uid
username
...
company_id
company table
company_id
company_name
...
Then, user.company_id would be a foreign key, that references company.company_id.
And, then, you store :
One line in user for each user
Referencing the id of the right company for that user
which is the company_id of the right line in the company table.
And one line for each company in company
There is no user's related information stored in the company table -- and as each user "points" to a company, a company can have several users.
Storing data as an array like you suggested is definitely not quite a good idea -- just not the way a relational database works.
If each user can have several companies, and each comparny can have several users, you'll have to add a third table (a join table), that will indicate, for each user(s), to which company(ies) they are attached to :
user table
uid
username
...
company table
company_id
company_name
...
user_company table
uid
company_id
In this situation, there is no user-related stuff in the company table, and there is no company-related stuff in the user table : the link between those is in the user_company table.
Of course, user_company.uid will be a foreign-key to user.uid ; and user_company.company_id will be a foreign-key to company.company_id.
There is a better idea - it's called a cross-table join. What you do is you create a third table, which contains two columns. In those two columns you store the primary key of the tables you're connecting to eachother.
The idea is that you're creating a relation between a company and a user. In a relational database, relations are indicated between tables by using foreign keys.
Of course, this only applies when you want to connect multiple users to multiple companies (an "M-N" relationship). If you want to connect multiple users to a single company, simply add a column for the company id to the user.
Any relational database is a good way to go. Have a look at MS SQL or MySQL.