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
Related
My teacher asked us to select from a 1:1 table called Employee; the supervisor and their role, and each employee they supervise with their role (employee is the primary key and those are the only 3 values in the table).
A 1:1 relationship are two tables with only one possible matching id.
It assumes that each supervisors only has one employee. so your query would look something like this.
SELECT Employee.Name, Employee.Role, supervise.Name, supervise.Role
FROM Employee
INNER JOIN supervise
ON Employee.EmployeeId = Supervise.EmployeeId
However, do note that in a real world context. This should have been a 1:N (One-To-Many) as each supervisors can have many employees.
Usually a 1:1 relationships are only used when you want to extended a table that you have no access or cannot modify. Otherwise, you would just add more columns to that original table. (or if you are working with a very old database system and you reach the max number of columns)
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 looked for this and did not find a solution that would apply to my scenario.
I'm building a database of game devs and I wish to generate a connections table:
I have the following:
Employee
(
name, date of birth, department they work at, task they do
)
Department
(
department name
)
Task
(
task name
)
and I need to generate a connections table that shows which department contributes to which task. I would do that by checking for each employee their department (only one) and task (also only one) and upon a match, the department contributes to that task.
That is the idea but I have to clue how to code it using Oracle
SELECT DISTINCT "department they work at", "task they do"
FROM Employee;
You should first work out an entity-relationship diagram, that lists the entities you use and with what attributes (and which primary keys), and the relations between those entities. Relationships can be: 1-to-1, 1-to-many and many-to-1, and many-to-many.
In the last case (M:N relation), the implementation in database tables requires an extra table to record such a M:N relationship.
The way to implement a 1:N relationship in a table is adding a foreign key in the child table to the primary key of the parent table.
EDIT: I see that you now supplied some details, and it is clear now that EMPLOYEE table is in fact the connection table, so you could simply query that table and show the DEPTID and TASKID (both the primary keys of their respective tables) to have a connection between departments and tasks. See the query in the other answer, and just add an ORDERBY on DEPTID, to show results in the order of DEPTID.
Let's say I have Employee & Meeting tables.
Employee
-----------
id
name
Meeting
-----------
id
name
Employee_Meeting
-----------
id
employee_id
meeting_id
Now I need to add employee's tasks (or anything else) in that meeting. What is a best practice to do that? I could have a relationships like this:
Employee_Meeting_Task
-----------
Employee_Meeting_id
task_id
or
Employee_Tasks
-----------
id
employee_id
meeting_id
task_id
Are both these approaches valid from 'proper' database design point of view?
My concerns are:
Case 1: Most of the time if I remove employee from the meeting I need to remove his tasks in that meeting as well. Employee_Meeting_Task would enforced that by constraint.
Case 2: Sometimes employee participates some daily meeting and regularly does same tasks in that meeting. If he got sick for several days, I would like to remove him from the meeting, but I don't want to re-add his tasks to the meeting next time he participates it.
There are a couple of things you should look at. First, if it's possible for an employee to have a task that is not associated with a meeting, you might be in trouble. One way out of it is to have a record in the meeting table with a name like "not applicable". Another way is to take the meeting_id field out of the employee_tasks table. The best way depends on the requirement to associate tasks with meetings, which is something you have to ask your taskmaster about.
Next, for many to many tables, you don't need a separate id field. For example, for employee_meeting, the PK could be the employee_id and meeting_id.
Next, look at what you said for Case 2. If there is a daily meeting, would that not be one record in your meeting table for each day?