Как смоделировать отношения ядро-данные, один к одному или один ко многим?

Question

У меня есть объект Customer и объект Loan.Это отношения один-ко-многим (Клиент <- >> Кредит).Каждый заем имеет ровно 5 типов планов выплат (ровно 5 и не изменится в течение следующих 100 лет), чтобы клиент мог выбрать и просмотреть прогноз платежей.Каждый план выплат состоит из типа, начального платежа, ежемесячного платежа, процентов, количества платежей, общей суммы платежей, процентов и дат выплат.Как лучше всего смоделировать объект Payoff?

Вариант 1:

Каждый заем имеет пять отношений с объектом выплат, представляющих пять различных планов выплат.т. е. внутри объекта Loan существует 5 отношений payoffPlanA, payoffPlanB, payoffPlanC, payoffPlanD, payoffPlanE к объекту Payoff.

Вариант 2:

Каждый кредит имеет отношение один ко многим (Loan <- >> Выплата).Чтобы получить конкретный план выплат, приложение проверит из списка объектов выплат для атрибута типа объекта выплаты.Например, чтобы приложение отображало содержимое Плана выплат C, приложению необходимо будет просмотреть список объектов выплат для ссуды и проверить, является ли тип Планом C, а затем получить сведения.

Естьесть другие варианты?Спасибо

Answer 1

Мне не кажется, что планы выплат на самом деле являются данными. Они звучат как кусочки логики, которые будут работать с данными, предоставленными объектами Customer и Loan. Другими словами, логика каждого из пяти типов планов является общей, и только предоставленные данные дают разные результаты.

Если это так, то вам, вероятно, не нужны или не нужны сущности базовых данных, представляющие планы выплат. Вместо этого вы должны создавать обычные, т.е. неуправляемые объекты, которые принимают методы, которые принимают объекты Customer и Loan в качестве входных данных. При необходимости вы можете прикрепить их к неуправляемым свойствам (которые не отображаются в сущности) для классов Customer и Loan.

Если Планы выплат на самом деле являются данными и уникальны в графе объектов, тогда лучше выбрать вариант (2).

Answer 2

Не используйте вариант 1.

Как только у вас появятся такие поля, как PayOffPlanA - ..F, у вас возникнут проблемы.Отчеты, запросы на сопровождение и тому подобное ненавидят такого рода денормализацию и дадут вам только головную боль и дополнительную работу.

Еще один объект / таблица не имеет недостатков.Вы можете денормализовать выбранный план в кредит, используя триггеры или хранимые процедуры, но на самом деле это просто для демонстрации.Ваша таблица типов выплат невелика и не обновлена, поэтому она находится в кеше базы данных.

(и никогда не говорите никогда, даже 100 лет - жизнь меняется)

ATB// Том Джад

Answer 3

Я бы выбрал вариант 2, но если вы хотите немного большей гибкости в дизайне, я думаю, вариант 3 будет выглядеть следующим образом:

вариант 3: Заказчик <- >>Заем <- >> PayOff <-> PayOffType

При использовании варианта 3, если новые PayOffTypes приходят или меняются через 100 лет, вам не нужно менять схему.