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
