I have a type of data called a chain
. Each chain
is made up of a specific sequence of another type of data called a step
. So a chain
is ultimately made up of multiple steps
in a specific order. I'm trying to figure out the best way to set this up in MySQL that will allow me to do the following:
I'm currently considering the following table set up as the appropriate solution:
TABLE chains
id date_created
TABLE steps
id description
TABLE chains_steps (this would be used for joins)
chain_id step_id step_position
In the table chains_steps
, the step_position
column would be used to order the steps in a chain correctly. It seems unusual for a JOIN table to contain its own distinct piece of data, such as step_position
in this case. But maybe it's not unusual at all and I'm just inexperienced/paranoid.
I don't have much experience in all this so I wanted to get some feedback. Are the three tables I suggested the correct way to do this? Are there any viable alternatives and if so, what are the advantages/drawback?
You're doing it right.
Consider a database containing the Employees
and Projects
tables, and how you'd want to link them in a many-to-many fashion. You'd probably come up with an Assignments
table (or Project_Employees
in some naming conventions).
At some point you'd decide you want not only to store each project assignment, but you'd also want to store when the assignment started, and when it finished. The natural place to put that is in the assignment itself; it doesn't make sense to store it either with the project or with the employee.
In further designs you might even find it necessary to store further information about the assignment, for example in an employee review process you may wish to store feedback related to their performance in that project, so you'd make the assignment the "one" end of a relationship with a Review
table, which would relate back to Assignments
with a FK on assignment_id
.
So in short, it's perfectly normal to have a junction table that has its own data.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments