Hi Ashish,
please see my comment below:
On Jun 30, 2008, at 7:50 AM, Ashish Vijaywargiya wrote:
The reason of keeping the field(statusChangeNote) in WorkEffort
entity was
that you don't directly update the values in the WorkEffortStatus
table. If
you update the value for the "status" in the WorkEffort table then the
changed value will also gets saved in the WorkEffortStatus table for
maintaining the History of status.
I am confused that how should we maintain the value in the
WorkEffortStatus.reason field.Because the value in WorkEffortStatus
comes on
changing the value in WorkEffort table.Please let me know your
thoughts on
this so I will get the better insight on the scenario of keeping
only the
"reason" field in WorkEffortStatus table.
The (current)statusId in the WorkEffort entity is a somewhat redundant
field (denormalized) because the master information is in the
WorkEffortStatus entity; the reason we keep it is to make it easy and
fast to get the current status of the WorkEffort; if there is code
that creates a WorkEffortStatus entry when the statusId of the
WorkEffort is changed, then this should be interpreted as a
convenience method of keeping the data model synchronized. We should
"read" it in the following way:
"updateWorkEffort to newStatus" --> create a new WorkEffortStatus
entry --> update the statusId field in the WorkEffort entity to
reflect the new entry in the WorkEffortStatus
and not in the following way:
"updateWorkEffort to newStatus" --> update the statusId field in the
WorkEffort entity --> create a new WorkEffortStatus entry to reflect
the new statusId in the WorkEffort entity
So, if we do something like:
"updateWorkEffort to newStatus with reason someReason" --> create a
new WorkEffortStatus entry (setting newStatus and someReason) -->
update the statusId field in the WorkEffort entity to reflect the new
entry in the WorkEffortStatus
If we really need to do a lot of queries (but I don't think we have
to) on the last reason for the last status change, then we may think
to add the (last)reason in the WorkEffort... but again, I don't think
we need to add this information right now... that is why I guess David
suggested to suppress that field.
Cheers,
Jacopo