How to model core-data relationship, one-to-one or one-to-many?

I have Customer object and Loan object. It is a one-to-many relationship (Customer <-->> Loan). Each loan has exactly 5 type of Payoff plans (exactly 5 and will not change for the next 100 years) for customer to select and to see the payment projection. Each Payoff plan consist of type, initial-payment, monthly-payment, interest, number-installments, total-payment, total-interest and payoff-date. What's the best way to model the Payoff object?

Option 1:

Each Loan has five relationship to Payoff object representing the five different payoff plan. i.e. inside Loan object, there are 5 relationships payoffPlanA, payoffPlanB, payoffPlanC, payoffPlanD, payoffPlanE to Payoff object.

Option 2:

Each loan has a one-to-many relationship (Loan <-->> Payoff). To obtain a particular Payoff plan, t开发者_StackOverflowhe app will check from the list of Payoff objects for the type attribute of Payoff object. For example, for the app to display the content of Payoff Plan C, the app will need to traverse the list of Payoff objects for the loan and check if the type is Plan C, then retrieve the details.

Are there other options? Thanks

---

It doesn't sound to me like the Payoff Plans are actually data. They sound like chunks of logic that will operate on the data supplied by Customer and Loan objects. In other words, the logic of each the five plan types is generic and only the provided data produce different outputs.

If so, then you probably don't need or want Core Data entities representing the Payoff Plans. Instead, you should create ordinary i.e. non-managed objects, that accept have methods that accept a Customer and Loan objects as inputs. If necessary, you can attach those to unmanaged properties (ones that don't appear in the entity) for the Customer and Loan classes.

If the Payoff Plans are in fact data and unique in the object graph then choice (2) is best.

---

I would go with Option 2, but if you want a bit more flexibility in the design I think Option 3 would look like this:

option 3: Customer<->>Loan<->>PayOff<->PayOffType

With Option 3, the if new PayOffTypes come in or change after 100 years, you don’t have to change the schema.

---

Stay out of option 1.

As soon as you have fields such as PayOffPlanA - ..F you're in for trouble. Reports, maintainence-queries and such hates that kind of denormalisation, and will only give you headache and extra work.

Just one more object/table has no downsides. You may denormalize the selected plan into the loan, using triggers or stored procedures, but that's really just for showing off. Your payofftype-table isn't big, and not updated either, so it's in the db-cache.

(and never say never, not even 100 years - life is change)

ATB //tom joad