tags:

views:

12

answers:

1

I have different types of resources that can be assigned to a job. My resources, for now, are technicians and equipment. I would like to be able to store old assignments (aka, no static column in the resource tables referencing the job table).

I've been considering using a table for each resource that tracks assignments, but I would like to know if there is an ideal solution.

My tables are (for illustrative purposes):

TABLE equipment (
    id,
    type,
    PRIMARY KEY (id)
)
TABLE technicians (
    id,
    name,
    level,
    PRIMARY KEY (id)
)
TABLE jobs (
    jobno,
    starts,
    ends
    PRIMARY KEY (jobno)
)
TABLE table equipment_assignments (
    id,
    jobno,
    PRIMARY KEY (id, jobno),
    FORIEGN KEY (id) REFERENCES equipment(id),
    FORIEGN KEY (jobno) REFERENCES jobs(jobno)
)
TABLE table technician_assignments (
    id,
    jobno,
    PRIMARY KEY (id, jobno),
    FORIEGN KEY (id) REFERENCES technicians(id),
    FORIEGN KEY (jobno) REFERENCES jobs(jobno)
)
+1  A: 

Another way of doing this is to introduce a resource table that equipment and technician reference, or that contains a NULLable reference to equipment and technician. You then have resource assignments rather than entity specific assignments, I would argue that the former of these approaches makes it easier to introduce new resource types.

Will A
Do you kind of like a table that would have a single key, that technicians/equipment would reference for their id?
Eric Coutu
The way I envisage it is that the resource table has it's own id, and each technician / equipment references the resource table - the id of the technician / equipment need not match the resource id, though. Each resource is referenced by one-and-only-one technician or equipment. This approach also allows you to tack any resource-specific information on the resource entity rather than having potentially duplicated information on both technician and equipment.
Will A
So how would that be different from say having a table called resources that has an id column (say auto increment) then have technician/equipment tables that have a primary key called resource that is also a foreign key that references the resource.id? Or is this exactly what you are describing to me?
Eric Coutu
This is exactly the same - barring the constraint that the id of the resource is the same as the id of the entity referencing the resource. There's no reason not to do it this way - and it could make things simpler for you when it comes to querying.
Will A
Awesome, thanks alot! Makes alot of sense, I knew there was a simpler way when my resource assignment tables looked almost identical!
Eric Coutu
No problem - enjoy!
Will A