我有Customer对象和Loan对象。这是一对多关系（客户＆lt; - ＆gt;＆gt;贷款）。每笔贷款都有5种类型的支付计划（正好为5，并且在接下来的100年内不会改变），供客户选择和查看付款预测。每个支付计划包括类型，初始支付，每月支付，利息，数量分期付款，总付款，总利息和支付日期。为Payoff对象建模的最佳方法是什么？
选项1：
每笔贷款与Payoff对象有五种关系，代表五种不同的支付计划。即在Loan对象内部，有5个关系payoffPlanA，payoffPlanB，payoffPlanC，payoffPlanD，payoffPlanE到Payoff对象。
选项2：
每笔贷款都有一对多关系（贷款＆lt; - ＆gt;＆gt;支付）。为了获得特定的支付计划，应用程序将从支付对象列表中检查支付对象的类型属性。例如，要使应用程序显示支付计划C的内容，应用程序将需要遍历贷款的支付对象列表，并检查类型是否为计划C，然后检索详细信息。
还有其他选择吗？感谢
答案 0 :(得分：1)
对我来说听起来并不像支付计划实际上是数据。它们听起来像是对Customer和Loan个对象提供的数据进行操作的逻辑块。换句话说，每个五种计划类型的逻辑是通用的，只有提供的数据产生不同的输出。
如果是这样，那么您可能不需要或想要代表支付计划的核心数据实体。相反，您应该创建普通的，即非托管对象，接受具有接受Customer和Loan个对象作为输入的方法。如有必要，您可以将这些属性附加到Customer和Loan类的非托管属性（未在实体中显示的属性）。
如果支付计划实际上是对象图中的数据和唯一，那么选择（2）是最好的。
答案 1 :(得分：0)
我会使用选项2，但如果你想在设计上有更多的灵活性，我认为选项3看起来像这样：
选项3： 顾客＆LT; - ＆GT;＆GT;贷款＆LT; - ＆GT;＆GT;支付＆LT; - ＆GT; PayOffType
使用选项3，如果新的PayOffTypes在100年后进入或更改，则您不必更改架构。
答案 2 :(得分：0)
不要参加选项1.
只要你有像PayOffPlanA - ..F这样的字段，你就会遇到麻烦。报告，维护 - 查询和讨厌这种非规范化，只会让你头痛和额外的工作。
只有一个对象/表没有缺点。您可能使用触发器或存储过程将所选计划非规范化为贷款，但这实际上只是为了炫耀。你的payofftype-table不大，也没有更新，所以它在db-cache中。
（永远不要说永远，不要说100年 - 生活就是变化）
ATB //汤姆乔德