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
