http://ofbiz.116.s1.nabble.com/how-about-adding-a-paymentMethodName-to-PaymentMethod-tp169026p169037.html
find it). The reason OFBiz isn't normalized is
base, not becuase it's a modern system. Redundency
learning curve is steep in OFBiz. I just don't
nonnormalized. Denormalized data models are pursued
updates) to gain the advantages of query.
find it. The data we're talking about describes the
credit card, not the payment method. So, it makes
--- "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.
> >>>>
> >>>>>
>