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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
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
<[EMAIL PROTECTED]>
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
