TimeEntry versus WorkEffort

[Adrian Crum]

It seems to me that the TimeEntry entity duplicates the WorkEffort
entity. Why can't a time entry be a WorkEffort of type TIME_ENTRY?

I also noticed in the TimeSheet entity the fields partyId and
clientPartyId. Why isn't that information kept in TimesheetRole?

-Adrian

[David E Jones]

A basic tenet of data modeling (or the variety of it that we're  
shooting for with OFBiz) is to start with the concepts we want to  
model and then create literal entities for them and only combine two  
concepts when they are really similar.

In the Jira issue for temporal expressions (along with various old  
mailing list postings) I explained why we chose to combine tasks and  
calendar events into a single entity: WorkEffort (which is actually a  
concept based on The Data Model Resource Book). In a way I think using  
WorkEffort for a Project is a bit of a stretch, but so far it's been  
fine... mostly because a Project is more or less just a very high  
level task.

That's what matters most when considering whether to use the same or  
different entities is the concept behind them, and NOT whether or not  
they have similar fields, or even the same fields, on them. In fact,  
there are dozens of cases in OFBiz where entities have VERY similar  
fields. If you take that concept far enough you end up with a few  
generic entities that are reused for all sorts of things, and start to  
compromise and have generic field names like "stringInfo1" and other  
meaningless terms that depend 100% on context to determine what they  
are and mean. Take that to the extreme and you have just 2-3 tables in  
your database and have rows for fields of an entity (often called an  
"object" in those cases, to further dilute the meaning of the term)  
instead of columns, and use a global ID plus other meta data to figure  
out what each row is.

A TimeEntry is a very different concept from a WorkEffort, so even if  
we could put TimeEntry data into the WorkEffort entity we wouldn't  
want to.

On the same note, why not use the same entity for CustRequest, Quote,  
Order, and Invoice? They're all pretty similar aren't they? Also, why  
not use the same entity for ProdCatalog, ProductCategory, and even  
Product... they also all have pretty similar fields.... While we're at  
it, let's have just a single "EntityRole" entity that replaces all  
*Role and *Party entities that pretty much all have the same fields...

It's great to think about this sort of thing, and you can find  
hundreds of papers, articles, and even books along these lines. It  
doesn't mean it's a good direction in general for data modeling, and  
there are also plenty of papers, articles, and books that preach the  
opposite. A lot of the concepts in this direction are popular in the  
academic world, which makes sense because in that world people like to  
throw of real world constraints and practicality to explore new  
things. So far all they've made is a mess, and people with a more  
practical perspective generally don't go for it. I suppose it goes  
back to the seduction of ultimate flexibility... when in reality we  
want as many constraints as possible because more constraints limit  
the scope of what we have to deal with and made our jobs easier. Sorry  
if that's way too much of a generality... it's kind of a basic aspect  
of practicality IMO.

-David


On Sep 17, 2008, at 11:27 AM, Adrian Crum wrote:

> It seems to me that the TimeEntry entity duplicates the WorkEffort  
> entity. Why can't a time entry be a WorkEffort of type TIME_ENTRY?
>
> I also noticed in the TimeSheet entity the fields partyId and  
> clientPartyId. Why isn't that information kept in TimesheetRole?
>
> -Adrian

[Adrian Crum]

David,

Thank you very much for the detailed explanation. I should have re-read
the chapter on Work Efforts - I had a misunderstanding of how they are used.

-Adrian


David E Jones wrote:

>
> A basic tenet of data modeling (or the variety of it that we're shooting
> for with OFBiz) is to start with the concepts we want to model and then
> create literal entities for them and only combine two concepts when they
> are really similar.
>
> In the Jira issue for temporal expressions (along with various old
> mailing list postings) I explained why we chose to combine tasks and
> calendar events into a single entity: WorkEffort (which is actually a
> concept based on The Data Model Resource Book). In a way I think using
> WorkEffort for a Project is a bit of a stretch, but so far it's been
> fine... mostly because a Project is more or less just a very high level
> task.
>
> That's what matters most when considering whether to use the same or
> different entities is the concept behind them, and NOT whether or not
> they have similar fields, or even the same fields, on them. In fact,
> there are dozens of cases in OFBiz where entities have VERY similar
> fields. If you take that concept far enough you end up with a few
> generic entities that are reused for all sorts of things, and start to
> compromise and have generic field names like "stringInfo1" and other
> meaningless terms that depend 100% on context to determine what they are
> and mean. Take that to the extreme and you have just 2-3 tables in your
> database and have rows for fields of an entity (often called an "object"
> in those cases, to further dilute the meaning of the term) instead of
> columns, and use a global ID plus other meta data to figure out what
> each row is.
>
> A TimeEntry is a very different concept from a WorkEffort, so even if we
> could put TimeEntry data into the WorkEffort entity we wouldn't want to.
>
> On the same note, why not use the same entity for CustRequest, Quote,
> Order, and Invoice? They're all pretty similar aren't they? Also, why
> not use the same entity for ProdCatalog, ProductCategory, and even
> Product... they also all have pretty similar fields.... While we're at
> it, let's have just a single "EntityRole" entity that replaces all *Role
> and *Party entities that pretty much all have the same fields...
>
> It's great to think about this sort of thing, and you can find hundreds
> of papers, articles, and even books along these lines. It doesn't mean
> it's a good direction in general for data modeling, and there are also
> plenty of papers, articles, and books that preach the opposite. A lot of
> the concepts in this direction are popular in the academic world, which
> makes sense because in that world people like to throw of real world
> constraints and practicality to explore new things. So far all they've
> made is a mess, and people with a more practical perspective generally
> don't go for it. I suppose it goes back to the seduction of ultimate
> flexibility... when in reality we want as many constraints as possible
> because more constraints limit the scope of what we have to deal with
> and made our jobs easier. Sorry if that's way too much of a
> generality... it's kind of a basic aspect of practicality IMO.
>
> -David
>
>
> On Sep 17, 2008, at 11:27 AM, Adrian Crum wrote:
>
>> It seems to me that the TimeEntry entity duplicates the WorkEffort
>> entity. Why can't a time entry be a WorkEffort of type TIME_ENTRY?
>>
>> I also noticed in the TimeSheet entity the fields partyId and
>> clientPartyId. Why isn't that information kept in TimesheetRole?
>>
>> -Adrian
>
>

[Jacques Le Roux]

Thanks for the insight David !

Jacques

From: "David E Jones" <[hidden email]>

>
> A basic tenet of data modeling (or the variety of it that we're  
> shooting for with OFBiz) is to start with the concepts we want to  
> model and then create literal entities for them and only combine two  
> concepts when they are really similar.
>
> In the Jira issue for temporal expressions (along with various old  
> mailing list postings) I explained why we chose to combine tasks and  
> calendar events into a single entity: WorkEffort (which is actually a  
> concept based on The Data Model Resource Book). In a way I think using  
> WorkEffort for a Project is a bit of a stretch, but so far it's been  
> fine... mostly because a Project is more or less just a very high  
> level task.
>
> That's what matters most when considering whether to use the same or  
> different entities is the concept behind them, and NOT whether or not  
> they have similar fields, or even the same fields, on them. In fact,  
> there are dozens of cases in OFBiz where entities have VERY similar  
> fields. If you take that concept far enough you end up with a few  
> generic entities that are reused for all sorts of things, and start to  
> compromise and have generic field names like "stringInfo1" and other  
> meaningless terms that depend 100% on context to determine what they  
> are and mean. Take that to the extreme and you have just 2-3 tables in  
> your database and have rows for fields of an entity (often called an  
> "object" in those cases, to further dilute the meaning of the term)  
> instead of columns, and use a global ID plus other meta data to figure  
> out what each row is.
>
> A TimeEntry is a very different concept from a WorkEffort, so even if  
> we could put TimeEntry data into the WorkEffort entity we wouldn't  
> want to.
>
> On the same note, why not use the same entity for CustRequest, Quote,  
> Order, and Invoice? They're all pretty similar aren't they? Also, why  
> not use the same entity for ProdCatalog, ProductCategory, and even  
> Product... they also all have pretty similar fields.... While we're at  
> it, let's have just a single "EntityRole" entity that replaces all  
> *Role and *Party entities that pretty much all have the same fields...
>
> It's great to think about this sort of thing, and you can find  
> hundreds of papers, articles, and even books along these lines. It  
> doesn't mean it's a good direction in general for data modeling, and  
> there are also plenty of papers, articles, and books that preach the  
> opposite. A lot of the concepts in this direction are popular in the  
> academic world, which makes sense because in that world people like to  
> throw of real world constraints and practicality to explore new  
> things. So far all they've made is a mess, and people with a more  
> practical perspective generally don't go for it. I suppose it goes  
> back to the seduction of ultimate flexibility... when in reality we  
> want as many constraints as possible because more constraints limit  
> the scope of what we have to deal with and made our jobs easier. Sorry  
> if that's way too much of a generality... it's kind of a basic aspect  
> of practicality IMO.
>
> -David
>
>
> On Sep 17, 2008, at 11:27 AM, Adrian Crum wrote:
>
>> It seems to me that the TimeEntry entity duplicates the WorkEffort  
>> entity. Why can't a time entry be a WorkEffort of type TIME_ENTRY?
>>
>> I also noticed in the TimeSheet entity the fields partyId and  
>> clientPartyId. Why isn't that information kept in TimesheetRole?
>>
>> -Adrian
>