It appears to me that there is a one-to-one relationship between a fixed
asset maintenance and a work effort to perform the maintenance. Wouldn't it be better if there was a one-to-many relationship? Let's say I have a company truck fixed asset. I set up two maintenances for it: oil change every 5000 miles and tire rotation every 10000 miles. As I enter odometer readings in the Meter Reading section, the maintenances should generate oil change and tire rotation work efforts when the maintenance interval is passed. What do you think? -Adrian |
On Jun 4, 2008, at 11:51 AM, Adrian Crum wrote: > It appears to me that there is a one-to-one relationship between a > fixed asset maintenance and a work effort to perform the > maintenance. Wouldn't it be better if there was a one-to-many > relationship? > > Let's say I have a company truck fixed asset. I set up two > maintenances for it: oil change every 5000 miles and tire rotation > every 10000 miles. As I enter odometer readings in the Meter Reading > section, the maintenances should generate oil change and tire > rotation work efforts when the maintenance interval is passed. If I remember right the intent of the maintenance records is to have one for each part that must be maintained. In this case there would be one maintenance for the oil change and another for the tire rotation, even though they happen at the same intervals. I I understand you right the constraint you are looking at is the ProductMaint.maintTemplateWorkEffortId field that refers to a single WorkEffort, and you would like to have more than one WorkEffort associated with the ProductMaint record. On a side note, the relationship from ProductMaint to WorkEffort is many-to-one (as opposed to a one-to-one, meaning they would have the same primary key) because there can be many ProductMaint records for a single WorkEffort record. You are proposing to make it a many-to-many relatonship, which means a join entity to go between them would be needed. One thing to keep in mind: the way WorkEfforts are designed a single WorkEffort as a task or whatever can have various sub-WorkEfforts associated with it. -David |
David E Jones wrote:
> > On Jun 4, 2008, at 11:51 AM, Adrian Crum wrote: > >> It appears to me that there is a one-to-one relationship between a >> fixed asset maintenance and a work effort to perform the maintenance. >> Wouldn't it be better if there was a one-to-many relationship? >> >> Let's say I have a company truck fixed asset. I set up two >> maintenances for it: oil change every 5000 miles and tire rotation >> every 10000 miles. As I enter odometer readings in the Meter Reading >> section, the maintenances should generate oil change and tire rotation >> work efforts when the maintenance interval is passed. > > If I remember right the intent of the maintenance records is to have one > for each part that must be maintained. In this case there would be one > maintenance for the oil change and another for the tire rotation, even > though they happen at the same intervals. Sorta like that. Two maintenances, different intervals. > I I understand you right the constraint you are looking at is the > ProductMaint.maintTemplateWorkEffortId field that refers to a single > WorkEffort, and you would like to have more than one WorkEffort > associated with the ProductMaint record. On a side note, the > relationship from ProductMaint to WorkEffort is many-to-one (as opposed > to a one-to-one, meaning they would have the same primary key) because > there can be many ProductMaint records for a single WorkEffort record. > You are proposing to make it a many-to-many relatonship, which means a > join entity to go between them would be needed. I wasn't referring to the entities - I was referring to the concept. It looks that way to me based upon how the component operates. > One thing to keep in mind: the way WorkEfforts are designed a single > WorkEffort as a task or whatever can have various sub-WorkEfforts > associated with it. Then there would have to be code to create sub tasks when intervals are passed. That seems like unnecessary complication to me, but I'll check into it. -Adrian |
On Jun 4, 2008, at 12:47 PM, Adrian Crum wrote: >> One thing to keep in mind: the way WorkEfforts are designed a >> single WorkEffort as a task or whatever can have various sub- >> WorkEfforts associated with it. > > Then there would have to be code to create sub tasks when intervals > are passed. That seems like unnecessary complication to me, but I'll > check into it. There is already some code to clone a WorkEffort and its sub- WorkEffort records. It is used for various things and may be helpful for this too. -David |
Cool. Thanks for your help!
David E Jones wrote: > > On Jun 4, 2008, at 12:47 PM, Adrian Crum wrote: > >>> One thing to keep in mind: the way WorkEfforts are designed a single >>> WorkEffort as a task or whatever can have various sub-WorkEfforts >>> associated with it. >> >> Then there would have to be code to create sub tasks when intervals >> are passed. That seems like unnecessary complication to me, but I'll >> check into it. > > There is already some code to clone a WorkEffort and its sub-WorkEffort > records. It is used for various things and may be helpful for this too. > > -David > > |
Free forum by Nabble | Edit this page |