how about adding a paymentMethodName to PaymentMethod?

[Si Chen-2]

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

[cjhowe]

"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
>

[Si Chen-2]

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
>>

[cjhowe]

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
> >>
>
>

[David E. Jones]

There is no description field or whatever, so this is fine. Should be considered optional and what not of course.

-David


Si Chen 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

[David E. Jones]

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
>>>>
>>
>

[cjhowe]

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
> >>>>
> >>
> >
>

[Si Chen-2]

On Jun 28, 2006, at 4:21 PM, Chris Howe wrote:

> Let me explain it differently.  The PaymentMethod
> entity is an entity of convenience, not an entity that
> describes anything.

No, it's an entity that describes a payment method.  There are some  
payment methods which have additional information specific to them,  
but then again there may be some other payment methods which don't  
require additional entities.
>
> 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.
>
But there is no description on CreditCard, EftAccount, nor is there  
an equivalent field.  So this is not the case right?
> 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?

Actually there's a real benefit.  If I just want to get the  
description of a PaymentMethod and it's on the PaymentMethod, it's  
very easy.  If I have to .getRelated based on the type of the  
PaymentMethod to another entity, it's a mess.

>
>
>
> --- 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
>>>>>>
>>>>
>>>
>>

[cjhowe]

Re first comment:

If a paymentMethod requires no additional entity what
is the name doing for you that the type isn't?

Re second comment (but there is no description on...):

I'm saying that there should be a
CreditCard.description, et al but not a
PaymentMethod.description.

Re third comment (if i have to .getRelated it's a
mess):

And if i'm only working with credit cards, I have to
.getRelated back to the PaymentMethod.  Isn't that the
same mess?  There's no benefit except for this
specific application.  You're sacrificing
normalization in the data model for coding ease that
doesn't run both ways.

Placing the description in the PaymentMethod for what
you're wanting to accomplish creates an inconsistant
dependency.


--- Si Chen <[hidden email]> wrote:

>
> On Jun 28, 2006, at 4:21 PM, Chris Howe wrote:
>
> > Let me explain it differently.  The PaymentMethod
> > entity is an entity of convenience, not an entity
> that
> > describes anything.
>
> No, it's an entity that describes a payment method.
> There are some  
> payment methods which have additional information
> specific to them,  
> but then again there may be some other payment
> methods which don't  
> require additional entities.
> >
> > 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.
> >
> But there is no description on CreditCard,
> EftAccount, nor is there  
> an equivalent field.  So this is not the case right?
> > 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?
>
> Actually there's a real benefit.  If I just want to
> get the  
> description of a PaymentMethod and it's on the
> PaymentMethod, it's  
> very easy.  If I have to .getRelated based on the
> type of the  
> PaymentMethod to another entity, it's a mess.
>
> >
> >
> >
> > --- 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
> >>>>>>
> >>>>
> >>>
> >>
>
>

[David E. Jones]

If each type of PaymentMethod might have a description on it (ie CreditCard, EftAccount, etc), then why not put if on the PaymentMethod entity? In fact, I think it's somewhat silly not to...

-David


Chris Howe wrote:

> Re first comment:
>
> If a paymentMethod requires no additional entity what
> is the name doing for you that the type isn't?
>
> Re second comment (but there is no description on...):
>
> I'm saying that there should be a
> CreditCard.description, et al but not a
> PaymentMethod.description.
>
> Re third comment (if i have to .getRelated it's a
> mess):
>
> And if i'm only working with credit cards, I have to
> .getRelated back to the PaymentMethod.  Isn't that the
> same mess?  There's no benefit except for this
> specific application.  You're sacrificing
> normalization in the data model for coding ease that
> doesn't run both ways.
>
> Placing the description in the PaymentMethod for what
> you're wanting to accomplish creates an inconsistant
> dependency.
>
>
> --- Si Chen <[hidden email]> wrote:
>
>> On Jun 28, 2006, at 4:21 PM, Chris Howe wrote:
>>
>>> Let me explain it differently.  The PaymentMethod
>>> entity is an entity of convenience, not an entity
>> that
>>> describes anything.
>> No, it's an entity that describes a payment method.
>> There are some  
>> payment methods which have additional information
>> specific to them,  
>> but then again there may be some other payment
>> methods which don't  
>> require additional entities.
>>> 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.
>>>
>> But there is no description on CreditCard,
>> EftAccount, nor is there  
>> an equivalent field.  So this is not the case right?
>>> 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?
>>
>> Actually there's a real benefit.  If I just want to
>> get the  
>> description of a PaymentMethod and it's on the
>> PaymentMethod, it's  
>> very easy.  If I have to .getRelated based on the
>> type of the  
>> PaymentMethod to another entity, it's a mess.
>>
>>>
>>>
>>> --- 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
>>>>>>>>
>>
>

[cjhowe]

Because it's an inconsistant dependency which makes it
nonnormalized.  Sure that's database design theory and
rules can be broken if there's enough benefit.

But consider the real world dificulties that arise
when you have incosistant dependency. If you're entire
application world is OFBiz, there is no problem.  But,
if you have an outside application pulling information
from the OFBiz database, it now has to go through
OFBiz's entity engine to get it or it has to be aware
that some of the credit card information is in the
PaymentMethod entity.  This is unnecessary if you keep
the data model normalized whenever possible.  It is
certainly possible in this instance.


--- "David E. Jones" <[hidden email]> wrote:

>
> If each type of PaymentMethod might have a
> description on it (ie CreditCard, EftAccount, etc),
> then why not put if on the PaymentMethod entity? In
> fact, I think it's somewhat silly not to...
>
> -David
>
>
> Chris Howe wrote:
> > Re first comment:
> >
> > If a paymentMethod requires no additional entity
> what
> > is the name doing for you that the type isn't?
> >
> > Re second comment (but there is no description
> on...):
> >
> > I'm saying that there should be a
> > CreditCard.description, et al but not a
> > PaymentMethod.description.
> >
> > Re third comment (if i have to .getRelated it's a
> > mess):
> >
> > And if i'm only working with credit cards, I have
> to
> > .getRelated back to the PaymentMethod.  Isn't that
> the
> > same mess?  There's no benefit except for this
> > specific application.  You're sacrificing
> > normalization in the data model for coding ease
> that
> > doesn't run both ways.
> >
> > Placing the description in the PaymentMethod for
> what
> > you're wanting to accomplish creates an
> inconsistant
> > dependency.
> >
> >
> > --- Si Chen <[hidden email]>
> wrote:
> >
> >> On Jun 28, 2006, at 4:21 PM, Chris Howe wrote:
> >>
> >>> Let me explain it differently.  The
> PaymentMethod
> >>> entity is an entity of convenience, not an
> entity
> >> that
> >>> describes anything.
> >> No, it's an entity that describes a payment
> method.
> >> There are some  
> >> payment methods which have additional information
> >> specific to them,  
> >> but then again there may be some other payment
> >> methods which don't  
> >> require additional entities.
> >>> 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.
> >>>
> >> But there is no description on CreditCard,
> >> EftAccount, nor is there  
> >> an equivalent field.  So this is not the case
> right?
> >>> 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?
> >>
> >> Actually there's a real benefit.  If I just want
> to
> >> get the  
> >> description of a PaymentMethod and it's on the
> >> PaymentMethod, it's  
> >> very easy.  If I have to .getRelated based on the
> >> type of the  
> >> PaymentMethod to another entity, it's a mess.
> >>
> >>>
> >>>
> >>> --- 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
> >>>>>>>>
> >>
> >
>

[David E. Jones]

There would be no reason to have to go through the Entity Engine just because of something like this, that's somewhat silly... sorry.

Regardless of the data model you have to be aware of the model in order to effectively get anything out of any database.

In this circumstance it is not anything new. Various fields required for the CreditCard, EftAccount, etc require the fields on the PaymentMethod entity. The same is true for Party. The same is true for ContactMech. The same is true for any set of entities in OFBiz that all share the same primary key, one of which entities will "own" that primary key.

That would make it non-normalized? Well of course! Why on earth would we want anything normalized in a modern system like OFBiz? The only reason for normalization in a data model traditionally is for performance, but at the often severe price of limiting flexibility, or perhaps more precisely: destroying flexibility.

This is one of many causes of out of control costs of enterprise systems that is simply not needed for modern hardware and database software.

Even 20 years ago it was a stupid idea. That's all there is to it. Anyone with any experience with optimization knows that you write for flexibility and simplicity, then test to find the performance bottlenecks and then you fix those bottlenecks only introducing complexity and limiting flexibility where _absolutely_ necessary (ie where no creativity can be applied to avoid it).

Perhaps saying it was a stupid idea is too harsh, and somewhat wrong. The normalization patterns are masterfully effective for optimization, but when applied preemptively instead of for optimization following the pattern described above. It was somewhat the case that for older hardware preemptively optimizing was necessary because if you waited it wouldn't change anything, you'd have to do those optimizations anyway.

These days, that simply isn't true. If it were true a package like OFBiz would be impossible because the implementation would have to be so specific to a certain set of requirements that it would be useless for other organizations, and even more so for other industries.

You can disagree with me all day if you want. I've been through this dozens of times with dozens of people who have experience with this older style of system or database. This is one of the more important keys to the success of OFBiz, and without it the project would simply not be what it is today, if it were at all...

-David


Chris Howe wrote:

> Because it's an inconsistant dependency which makes it
> nonnormalized.  Sure that's database design theory and
> rules can be broken if there's enough benefit.
>
> But consider the real world dificulties that arise
> when you have incosistant dependency. If you're entire
> application world is OFBiz, there is no problem.  But,
> if you have an outside application pulling information
> from the OFBiz database, it now has to go through
> OFBiz's entity engine to get it or it has to be aware
> that some of the credit card information is in the
> PaymentMethod entity.  This is unnecessary if you keep
> the data model normalized whenever possible.  It is
> certainly possible in this instance.
>
>
> --- "David E. Jones" <[hidden email]> wrote:
>
>> If each type of PaymentMethod might have a
>> description on it (ie CreditCard, EftAccount, etc),
>> then why not put if on the PaymentMethod entity? In
>> fact, I think it's somewhat silly not to...
>>
>> -David
>>
>>
>> Chris Howe wrote:
>>> Re first comment:
>>>
>>> If a paymentMethod requires no additional entity
>> what
>>> is the name doing for you that the type isn't?
>>>
>>> Re second comment (but there is no description
>> on...):
>>> I'm saying that there should be a
>>> CreditCard.description, et al but not a
>>> PaymentMethod.description.
>>>
>>> Re third comment (if i have to .getRelated it's a
>>> mess):
>>>
>>> And if i'm only working with credit cards, I have
>> to
>>> .getRelated back to the PaymentMethod.  Isn't that
>> the
>>> same mess?  There's no benefit except for this
>>> specific application.  You're sacrificing
>>> normalization in the data model for coding ease
>> that
>>> doesn't run both ways.
>>>
>>> Placing the description in the PaymentMethod for
>> what
>>> you're wanting to accomplish creates an
>> inconsistant
>>> dependency.
>>>
>>>
>>> --- Si Chen <[hidden email]>
>> wrote:
>>>> On Jun 28, 2006, at 4:21 PM, Chris Howe wrote:
>>>>
>>>>> Let me explain it differently.  The
>> PaymentMethod
>>>>> entity is an entity of convenience, not an
>> entity
>>>> that
>>>>> describes anything.
>>>> No, it's an entity that describes a payment
>> method.
>>>> There are some  
>>>> payment methods which have additional information
>>>> specific to them,  
>>>> but then again there may be some other payment
>>>> methods which don't  
>>>> require additional entities.
>>>>> 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.
>>>>>
>>>> But there is no description on CreditCard,
>>>> EftAccount, nor is there  
>>>> an equivalent field.  So this is not the case
>> right?
>>>>> 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?
>>>>
>>>> Actually there's a real benefit.  If I just want
>> to
>>>> get the  
>>>> description of a PaymentMethod and it's on the
>>>> PaymentMethod, it's  
>>>> very easy.  If I have to .getRelated based on the
>>>> type of the  
>>>> PaymentMethod to another entity, it's a mess.
>>>>
>>>>>
>>>>> --- 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
>>>>>>>>>>
>

[cjhowe]

Normalization is desired because it eliminates (or at
the least limits) redundency and reduces inconsistant
dependency (stuff is found where it makes sense to
find it).  The reason OFBiz isn't normalized is
because reduced redundency and reduced inconsistant
dependency are relatively recent goals of the code
base, not becuase it's a modern system.  Redundency
and inconsistant dependency is the reason why the
learning curve is steep in OFBiz.  I just don't
understand why you would want to  pursue inconsistant
dependency where a better alternative exists that
you're aware of prior to implementation.

Denormalized data models are quite different than
nonnormalized.  Denormalized data models are pursued
as optimization strategies when you're willing to
sacrifice update (because you now need to do multiple
updates) to gain the advantages of query.  

Normalized data model:
Only have CreditCard.description (et al)

Nonnormalized data model:
Only have Paymentmethod.description

Denormalized data model:
Have both CreditCard.description (et al) AND
PaymentMethod.description

And yes, you would have to go through the entity
engine (via the service engine) OR know that someone
put data into a table where you wouldn't expect to
find it.  The data we're talking about describes the
credit card, not the payment method.  So, it makes
sense for the data to be IN the CreditCard entity.


--- "David E. Jones" <[hidden email]> wrote:

>
> There would be no reason to have to go through the
> Entity Engine just because of something like this,
> that's somewhat silly... sorry.
>
> Regardless of the data model you have to be aware of
> the model in order to effectively get anything out
> of any database.
>
> In this circumstance it is not anything new. Various
> fields required for the CreditCard, EftAccount, etc
> require the fields on the PaymentMethod entity. The
> same is true for Party. The same is true for
> ContactMech. The same is true for any set of
> entities in OFBiz that all share the same primary
> key, one of which entities will "own" that primary
> key.
>
> That would make it non-normalized? Well of course!
> Why on earth would we want anything normalized in a
> modern system like OFBiz? The only reason for
> normalization in a data model traditionally is for
> performance, but at the often severe price of
> limiting flexibility, or perhaps more precisely:
> destroying flexibility.
>
> This is one of many causes of out of control costs
> of enterprise systems that is simply not needed for
> modern hardware and database software.
>
> Even 20 years ago it was a stupid idea. That's all
> there is to it. Anyone with any experience with
> optimization knows that you write for flexibility
> and simplicity, then test to find the performance
> bottlenecks and then you fix those bottlenecks only
> introducing complexity and limiting flexibility
> where _absolutely_ necessary (ie where no creativity
> can be applied to avoid it).
>
> Perhaps saying it was a stupid idea is too harsh,
> and somewhat wrong. The normalization patterns are
> masterfully effective for optimization, but when
> applied preemptively instead of for optimization
> following the pattern described above. It was
> somewhat the case that for older hardware
> preemptively optimizing was necessary because if you
> waited it wouldn't change anything, you'd have to do
> those optimizations anyway.
>
> These days, that simply isn't true. If it were true
> a package like OFBiz would be impossible because the
> implementation would have to be so specific to a
> certain set of requirements that it would be useless
> for other organizations, and even more so for other
> industries.
>
> You can disagree with me all day if you want. I've
> been through this dozens of times with dozens of
> people who have experience with this older style of
> system or database. This is one of the more
> important keys to the success of OFBiz, and without
> it the project would simply not be what it is today,
> if it were at all...
>
> -David
>
>
> Chris Howe wrote:
> > Because it's an inconsistant dependency which
> makes it
> > nonnormalized.  Sure that's database design theory
> and
> > rules can be broken if there's enough benefit.
> >
> > But consider the real world dificulties that arise
> > when you have incosistant dependency. If you're
> entire
> > application world is OFBiz, there is no problem.
> But,
> > if you have an outside application pulling
> information
> > from the OFBiz database, it now has to go through
> > OFBiz's entity engine to get it or it has to be
> aware
> > that some of the credit card information is in the
> > PaymentMethod entity.  This is unnecessary if you
> keep
> > the data model normalized whenever possible.  It
> is
> > certainly possible in this instance.
> >
> >
> > --- "David E. Jones" <[hidden email]> wrote:
> >
> >> If each type of PaymentMethod might have a
> >> description on it (ie CreditCard, EftAccount,
> etc),
> >> then why not put if on the PaymentMethod entity?
> In
> >> fact, I think it's somewhat silly not to...
> >>
> >> -David
> >>
> >>
> >> Chris Howe wrote:
> >>> Re first comment:
> >>>
> >>> If a paymentMethod requires no additional entity
> >> what
> >>> is the name doing for you that the type isn't?
> >>>
> >>> Re second comment (but there is no description
> >> on...):
> >>> I'm saying that there should be a
> >>> CreditCard.description, et al but not a
> >>> PaymentMethod.description.
> >>>
> >>> Re third comment (if i have to .getRelated it's
> a
> >>> mess):
> >>>
> >>> And if i'm only working with credit cards, I
> have
> >> to
> >>> .getRelated back to the PaymentMethod.  Isn't
> that
> >> the
> >>> same mess?  There's no benefit except for this
> >>> specific application.  You're sacrificing
> >>> normalization in the data model for coding ease
> >> that
> >>> doesn't run both ways.
> >>>
> >>> Placing the description in the PaymentMethod for
> >> what
> >>> you're wanting to accomplish creates an
> >> inconsistant
> >>> dependency.
> >>>
> >>>
> >>> --- Si Chen <[hidden email]>
> >> wrote:
> >>>> On Jun 28, 2006, at 4:21 PM, Chris Howe wrote:
> >>>>
> >>>>> Let me explain it differently.  The
> >> PaymentMethod
> >>>>> entity is an entity of convenience, not an
> >> entity
> >>>> that
> >>>>> describes anything.
> >>>> No, it's an entity that describes a payment
> >> method.
> >>>> There are some  
> >>>> payment methods which have additional
> information
> >>>> specific to them,  
> >>>> but then again there may be some other payment
> >>>> methods which don't  
> >>>> require additional entities.
> >>>>> 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.
> >>>>>
> >>>> But there is no description on CreditCard,
> >>>> EftAccount, nor is there  
> >>>> an equivalent field.  So this is not the case
> >> right?
> >>>>> 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?
> >>>>
> >>>> Actually there's a real benefit.  If I just
> want
> >> to
> >>>> get the  
> >>>> description of a PaymentMethod and it's on the
> >>>> PaymentMethod, it's  
> >>>> very easy.  If I have to .getRelated based on
> the
> >>>> type of the  
> >>>> PaymentMethod to another entity, it's a mess.
> >>>>
> >>>>>
>

=== message truncated ===