I have a user table with userid (pk), password, usertype.
I have another table student with stdid (pk), stdname, stdaddress.
I have a third table faculty with facid (pk), facname, facaddress.
What I want to do is populate the user table with the pk from either student table or faculty table.
How do I implement this in SQL Server 2005.
Can someone help me?
Edited Below
In my database, the student and faculty table are already implemented as part of another module. I need to implement the authentication part over LAN to be able to be accessed from anywhere, so I can not restructure that part. So I am using the user table with userid (username) and password in that table.
The userid is either stdid or facid and also the pk of the user table.
What you have is a bad design. You do not want to use one or the other other PK as the PK in a table. This cannot every work. What happens when you try to insert student 10 (who is Joe Jones) but faculty 10 (Mary Smith) is already in the table. Well, the insert would fail becuse of the unique requirement of a PK.
If all studetns and faculty are always users, then userID is the PK and FacultyId and StudentID are the FKs to that table not the reverse.
insert into user_table (select facid as userid from facultaty_table union select stdid as userid from student_table)
this will leave column password and usertype as null otherwise it pumps up userid_table with all the PKs from the others
What are the data types of the keys? Is there a guarantee that they're going to be unique across both the student and faculty tables?
This seems like it's going to be a difficult design to work with over time. Maybe try moving the central focus from the "person" tables to the user table and assign roles from there? Something like this:
User
------
Id
Password
UserType
(where's the username?)
UserInfo
------
UserID
Name
Address
Role
------
Id
Name
UserRole
------
UserID
RoleID
(The Role table would have at least two records, one called "Student" and one called "Faculty", but could allow for more roles as well.)
There are a few benefits here:
You need only store names and addresses in one place, rather than duplicate the model across different roles.
A user can have multiple roles. For example, a faculty member could take some classes and be a "student" for a while. A grad student can teach some classes and be a "faculty member" for a while.
New roles can be added without having to change the data model.
Related
Let's assume I am building the backend of a university management software.
I have a users table with the following columns:
id
name
birthday
last_english_grade
last_it_grade
profs table columns:
id
name
birthday
I'd like to have a third table with which I can determine all professors teaching a student.
So I'd like to assign multiple teachers to each student.
Those Professors may change any time.
New students may be added any time too.
What's the best way to achieve this?
The canonical way to do this would be to introduce a third junction table, which exists mainly to relate users to professors:
users_profs (
user_id,
prof_id,
PRIMARY KEY (user_id, prof_id)
)
The primary key of this junction table is the combination of a user and professor ID. Note that this table is fairly lean, and avoids the problem of repeating metadata for a given user or professor. Rather, user/professor information remains in your two original tables, and does not get repeated.
Table Department:
DeptId
Name
Table Team
TeamId
*DeptId (FK)
Name
Table Employee
EmpId
*DeptId
*TeamId
I am making some updates on an old project, but I don't know why the old programmer designed those tables like this (like putting both DeptId and TeamId in the Employee table).
I find this useless because I can get the department from the Team table, and there's no need to put both FK IDs into the Employee table, TeamId is enough.
Is there any other reason that could force me to put both FKs in that table?
Thank you.
As the data model is written, an employee could be a member of a team that is not in his or her department.
That is probably possible, for instance, if the employee is temporarily on loan.
My bigger problem with the data model is that the relationships between employee and team and employee and department vary over time. So, I would have three tables for each entity. The only relationship in the tables would be between team and department (because that presumably does not change over time).
Then I would have two junction tables, one employeeDepartments and one employeeTeams that capture the changing relationships over time.
I have three tables in my database: Contacts (master table), Users and Staff. The Contacts table has a primary key that is referenced as a foreign key from the Users and Staff tables.
Contacts
ContactID (Primary Key)
First Name
Last Name
Email
Users:
ContactID (Foreign Key)
Username
Password
Staff:
ContactID (Foreign Key)
Position
Comments
Pulling data from these tables is fairly simple with INNER JOIN and depends what data you need from the Users or Staff table. Updating and inserting new records is something that I'm not sure which way to approach.
Since the Contacts table is my master table and holds unique ID's but at the same time is shared between Users and Staff, I'm not sure about this situation.
Let's say I want to enter new user record. I need to enter First, Last name and email into the Contacts table, and User Name and Password into the Users table. At the same time I have to check if First, Last name and email already exist in the Contacts table, since maybe this Contact record has been previously entered for a Staff record.
I'm not sure how to prevent duplicates but at the same time there might be user or staff with the same name. Should I limit/filter by email and not let them enter the records if the email already exist in contacts table? Or is there a better way to handle this?
The whole point of having three tables is to prevent redundant data since User might be a Staff, but Staff might not be a User if that make sense. If anyone can help me pick the best approach please let me know. Thanks
You have to start by using a SELECT query and whatever business rules you want to test to decide if you will perform the INSERT at all, or UPDATE an existing record instead.
Then if you are going to INSERT, you have to INSERT into Contacts first, get the newly inserted ID, and then INSERT into the other two tables.
I'm not sure about the best way to express a relationship between models in my Laravel 4 application. I have three models that I am using to store information in a database: Employer, Employee and User. Basically, the Employer and Employee models are just going to contain meta information about the User model. I think the following expression is the best I can think of:
Employer has many Employee
Employee belongs to one Employer
Employer belongs to one User
Employee belongs to one User
In the database, I am going to have a user_id foreign key in both the employers and employees tables that reference the id field in the users table. Is this the best way to model this domain?
It depends. Can an employee have more than one employer? Can an employee be employed at more than one place? Do you want to delete records if an employee leaves (and lose history)?
If you can delete the employee record when the employee leaves you can just have an employer_id field in the employee table. But just be prepared that you won't be able to easily add capabilities if you need them in the future.
If you want to prepare for the future: You might want to have a table that says
employer_id
employee_id
start_date
end_date
And even then if an employee comes and then leaves you have records with the same employer_id, employee_id. So that makes it look like you need an internal key and have say:
employment_record_id // this is the primary key
employer_id
employee_id
start_date
end_date
I'm not sure exactly what users are but ask yourself the same types of questions:
Can a user exist with an employee record
Can you have employees without a user record
Can a employees user record change
Can a users employee record change
I am currently trying to design a database where we have a table of students, table of subjects available and the table containing which students will choose which subjects based on a form they fill in. Similiar to an order system.
I think my design is rather simple and not reliable.
I currently have three tables:
TableModule:
ModuleID(PK),
ModuleName,
Semester,
Credits
TableModuleForm:
ID(PK),
StudentID,
ModuleID
TableStudent:
StudentID(PK),
Username,
Password,
Lastname,
Firstname,
Email,
Course,
StudyYear
Not quite sure if using 3 tables is the correct method. I am just a beginner in MS
What is a good method to design a database where students can choose multiple subjects they want to study all in one form?
*What sort of relationships should they have?
I currently have implemented a login form where it will allow access to the subject selection form after they have logged in using the correct username and password based on information in the students table. Thanks!
Student
id
name
username
password
Subject
id
name
StudentSubject
id
subject_id
student_id