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