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.
Related
I'm trying to make an Address book with different users in which they can log in with their username and password. And they can store the information like contact id, first name, last name, phone etc. I want each user to have his own address book.
Can someone please explain how I create different address book for different users.
Thanks a lot.
Create a database. take a primary id to each user or provide unique id.Then create another table fill the fields that you want(address book).Match the user who logged in and and with that another table(foreign key relationship).
When you login ..it checks with db then allows.After that you have to use insert ,update keywords for further process to put data in db.That particular unique id/primary key is used to fetch the related data(address book fields) of that user.
It is actually not a good question for StackOverflow but I will still roughly explain it to you.
You will need two different tables for this. The first one will be used for login details and the second one will record user's address book.
For example:
Table auth will have 3 columns id, username, password
Table addressBook will have contact id, first name, last name, phone etc and also have one more which will be called userID
Whenever any user eneter the data in addressBook their userID from auth table coloum id will be stored along with it. Now you can display their own data to the users.
If you have anymore question ask in comment here.
region, zone, district tables are all populated. User can get region, zone and district id from form each for temporary address and permanent address. What would be best database design for this:
Currently i am thinking of:
users table:
id name email region_id zone_id district_id tregion_id tzone_id tdistrict_id
but how can i make relation? 1 user can have 2 regions each for temporary address and permanent address? Even if i setup hasMany relations, wouldn't there be two foreign keys
in terms of region_id and tregion_id?
Having two different foreign keys to the same table is perfectly fine. in the model you can have two relations where you define the different keys:
public function region(){
return $this->belongsTo(Region::class, 'region_id');
}
public function tempRegion(){
return $this->belongsTo(Region::class, 'tregion_id');
}
You should go at least till 3NF for your database design and then you may not need to maintain different fields for Temporary and Permanent. Also to avoid redundancy like in case of multiple persons stays at same address then same address will be repeating.
Your design may alike;
1. User Table (id, name, email)
2. Address Table (id, region_id,zone_id,district_id)
To store two or more (future proof) numbers of user address (one to many), you will be needed a table for user-address assignment say UserAddress, this will look like as per following; Add an address identifier field say AddressType.
3. UserAddress(
Id, UserId (FK to User), AddressId (FK to Address Table),
AddressType (Permanent/Temporary))
Future Scope Improvement with least changes
Now you also have opportunity to maintain the dates, for which period a user has stayed in which address, in this case user address table will needs two more fields.
Id, UserId (FK to User), AddressId (FK to Address Table), AddressType, startDate, endDate, IsCurrent, IsRented and other desirable attributes ...
If will add one more field to UserTable table say IsCurrent, then you can directly query the user current address by simple AND condition;
AND IsCurrent=1;
I'm building a school project and my idea is to have a site where you can register an account, add a couple of users to that account and then calculate their monthly shared expense debt, e.g. User A pays 500 on groceries and user B only pays 250. This gives User B a debt of 125 to user A that month.
My problem is that I want to separate the accounts with the users. Now I have a setup of a table called Accounts with email and password and then I have a users table with particular user information. I want several people to be able to log in to the same account using different credentials.
Users table
ID, Name, Account_id etc.
Accounts table
ID, Email, Password, date_added, date_updated etc.
What is the best approach of doing this? Is it to have a cross-table called UsersForAccounts or do I specify several account_ids in the Users-table?
You wouldn't think of it as several users on one account. You would think of it as several user accounts that share a common group setting.
So you have a user's table as you may expect - each with its own values for that person, obviously.
Then you have a related table that shares the details for the group. Let's use a fraternity or something as an example.
SO you have Pi Phi as a group name. Within that are Users A, B and C.
A very very basic table structure might look like this:
Users: id, email, password, name, group_id
Group: id, name
So a user would - by this setup - have a relation to only one group. You could make that a relational table so a user can have many groups if you want.
The general idea here is that you use the group as a separate connection point to the user and not necessarily several users that access with the same account.
If that is unclear, feel free to ask and I may update
You can use a structure such as in the Users Table:
ID, Name, etc.
And in the Accounts table use simplest:
ID, Email, Password, date_added, date_updated, User_ID, etc
This is called Many to One relationship, and is ideal to your case.
A small tip i can pass to you is use LOWERCASE to ALL your fields, or in special to the first character of the name of the field, with an excerpt for "ID" (that is only a acronym (or similar) to Identification)
In an basic example, the Users table has the fields:
ID, name, etc.
And Accounts table the structure above:
ID, email, password, date_added, date_updated, user_id
This can't help much in a short time, but it can help you, and very much, at use of the database with PHP.
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
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.