Posted by
cjhowe on
Jun 29, 2006; 12:21am
URL: http://ofbiz.116.s1.nabble.com/how-about-adding-a-paymentMethodName-to-PaymentMethod-tp169026p169031.html
Let me explain it differently. The PaymentMethod
entity is an entity of convenience, not an entity that
describes anything. PaymentMethod pools together real
objects that are similar so that we can treat them as
if they are the same. Allow me to show an example of
the Party entity before the description field was
added to that.
First there were a few people:
John Doe
Jane Smith
Mike Hall
Then there were a bunch of Corpartions:
Acme
XYZ Corp
Widgets, Ltd
We realized that these two groups have some things in
common that we want to show together. So, we assign
each of them a PartyId. A Party entity isn't required
to show these two groups (people and corporations)
together.
However, out of convenience we create a Party entity
to make sure we don't assign a partyId to one person
and the same partyId to a corporation. At this point,
we are no longer normalized. We have to keep track of
the partyId in two different places. But that's okay,
the benefit of not assiging the same partyId to two
different parties outweighs the loss of normalization
(especially since we won't be changing the partyId
frequently - possibly ever). Now that this
relationship exists, by adding the partyType field we
can describe this Party record so that we can go to
Party from Person, to Person from Party, to
Corporation(PartyGroup) from Party and to Party from
Corporation. The fluidity outweighs not being
normalized with this field (especially since we won't
be changing the partyType often, if ever).
Because merely having Party broke normalization, every
field added to party won't be normalized.
So now we add description. But, there's already a
description (firstName, lastName) for Person and a
description (groupName) for Corporation. This is
information that is likely to change and we will need
to keep track of it in multiple locations when it is
unneccesary.
So, there's no benefit of adding the description, but
you've added the possibility of the nonnormalized data
to be inconsistant. Does that make a good data model?
--- David E Jones <
[hidden email]> wrote:
>
> Huh?
>
> Chris Howe wrote:
> > It may apply to all payment methods (I'm not
> really
> > sure that it applies to all current payment
> methods,
> > much less ALL that may exist), but it does not
> > describe the payment method. It describes the
> payment
> > method's child so it should go in the entity that
> it
> > is describing.
> >
> > Following through with the approach of putting the
> > field in PaymentMethod entity puts you in the
> position
> > of modifying the data to fit the data model
> instead of
> > keeping the data model flexible enough to fit the
> > data.
> >
> > --- Si Chen <
[hidden email]>
> wrote:
> >
> >> I disagree. This is a descriptive note that
> applies
> >> to all
> >> PaymentMethods so why put it in the child
> entities.
> >> If you had a
> >> parent class which had a field that all inherited
> >> classes should
> >> have, shouldn't be in the parent class?
> >>
> >>
> >>
> >> On Jun 28, 2006, at 1:35 PM, Chris Howe wrote:
> >>
> >>> "Bank A general account" does not describe the
> >>> PaymentMethod, it describes the credit card, the
> >>> company account, the gift card, etc so that
> field
> >>> should go on the CreditCard, etc entity. Now if
> >>> you're using it as an alias for the Payment
> >> Method,
> >>> then you should create a PaymentMethodAttribute
> >> entity
> >>> and make a relationship between the two.
> >>>
> >>>
> >>> On a side note. I've noticed a couple of fields
> >>> getting added onto entities in svn that are
> quick
> >>> fixes to gain functionality but cause a loss of
> >> the
> >>> entity's meaning. PaymentMethod.partyId is one
> >> that
> >>> quickly comes to mind.
> >>>
> >>> --- Si Chen <
[hidden email]>
> >> wrote:
> >>>> Hi everybody.
> >>>>
> >>>> What do you think of adding a field
> >>>> "paymentMethodName" to
> >>>> PaymentMethod, so a company can identify that
> >> method
> >>>> A is "Bank A
> >>>> general account", etc. etc.
> >>>>
> >>>> Si
> >>>>
> >>
> >
>