Subject: | |
From: | |
Reply To: | |
Date: | Thu, 27 Jan 2011 13:39:01 +0000 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Jason
In reference to Richard's question, it still sounds like you need a one-to-many relationship (not many-to-many).
A project has one or more tasks. Each task belongs to one project only. That's one(project)-to-many(tasks).
But I'm wondering if the terminology is getting in the way here? Does your Tasks table have one record per task per project? Or is it simply a list of all your available tasks? If the latter, I think I might see what you are getting at.
Maybe you mean this:
Projects –< Project_Tasks
[one] to [many]
Where Project_Tasks are the tasks assigned to a particular project (so there is one record per task per project). Project_Tasks are chosen from Tasks, which is the list of all possible tasks.
You might then want to extend to this:
Projects –< Project_Tasks >– Tasks
So that each task relates to the many instances of that task (one for each project that requires it); by storing only the Tasks id in Project_Tasks, you can display the details of the task from the Tasks table via the relationship.
Maybe what you want is a display, in the Projects record, of all Tasks that have not yet been assigned to the project (by creating a record in Project_Tasks). Doing this is not trivial and I think you need to make sure you have the correct data (relationship graph) structure as well as a suitable means of creating Project_Tasks with the appropriate ids before trying to implement it.
Does this help clear the fog at all?
Steve
On 27 Jan 2011, at 10:34, Jason Bourque wrote:
> Yes, there are many review steps that have to happen in a project for quality control. And other tasks like prepare files for output that might be in the projects "dealer product photo request" and "send label files to printer".
>
> I used the many to many so the details of those tasks wouldn't have to be updated in more than one location.
|
|
|