How do you create a table that can have x number of possible things joining into it?

# The problem I have a system that I'm building where I need to allow users to track time to any number of various other systems. For example, I have a concept called a Project, a project can contain 0 or many Tasks. Where each task can contain anything from equipment being used, materials being consumed, or other tasks which can have more of the same. Think a ghant chart. In this chart a user needs to be able to track time to the material being used, a vehicle being driven, or equipment being used. Right now I just track time to the project as a whole which doesn't allow the granularity that I need. ## Db schema outline This is a *VERY ROUGH* outline of what this might be like. It is not fully accurate to my schema but it should get the point across. There are more tables around time and projects and employees but think of this as a very abstracted version of the system. As more and more items need to track time they would need to be added to the Activities table which seems wrong. # Ideas One way I thought about solving this was having a join table that can join on 0-1 of a project, task, material, equipment, vehicle. This seems to work the problem here is as more things get added I'm just going to need to keep adding more and more foreign keys that wont get used as only one project, task, equipment, etc will ever be used at a time. This seems like a very inefficient way of doing this. Another way of doing this might be to have each item that can track time have a FK to the join table (currently called activities/effort) with that table not having any FK out to the tables that can use it, but still having a column for the ID of the thing that it ties back to, I wouldn't be able to enforce the relationships this way but it seems to be a decent solution. Especially if I break time management stuff into its own schema so it wouldn't know about other systems anyways. Basically this table would need more software to manage it and we would have to be very careful with what writes to it when but it seems like its likely the best solution at the moment. # The question Given the problem I have outlined does anyone have any ideas for how one might represent this kind of data? In case it matters our db is Postgres but this is more of an architectural design problem. # EDIT 1: I have been working on the problem a bit more and have another idea for how it could be done. I don't know that this is a solution just yet so I don't want to mark it as such. Basically it involves having my timecard table (replacing the activities one) have an id timeTrackingId where each employee can have multiple timecards (mapped via the timesheet). Each timecard tracks the time for one given trackable entity. So if an employee is tracking time to a project and 3 tasks then they will effectively have 4 timecards which whichever being tracked at any given time based on how the software decides. This here is an updated diagram.