Сделали новый проект и бизнес начинает менять условия, понимая, что надо по другому.

Сильно упрощенный пример
Вот пример: в таблице Payments теперь может быть запись если есть запись в таблице Approvals по данному пейменту.
То есть если платеж подтвержден директором.
Теперь Approval становится обязательным, а раньше был необязательным и соотвествующей записи там не было.

Основной вопрос такой: как такие изменения внедрять и как строить архитектуру, чтобы через год можно было понять почему нет апрувала?

Здравствуйте, peer, Вы писали:

P>Теперь Approval становится обязательным, а раньше был необязательным и соотвествующей записи там не было.
P>Основной вопрос такой: как такие изменения внедрять и как строить архитектуру, чтобы через год можно было понять почему нет апрувала?

В данном случае подойдет внешний ключ. Для неподтвержденных платежей не заполнять. Или можно проставить ссылку на некий виртуальный Approval, где в поле Description пояснить, что к чему.

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, peer, Вы писали:

P>>Теперь Approval становится обязательным, а раньше был необязательным и соотвествующей записи там не было.
P>>Основной вопрос такой: как такие изменения внедрять и как строить архитектуру, чтобы через год можно было понять почему нет апрувала?

W>В данном случае подойдет внешний ключ. Для неподтвержденных платежей не заполнять. Или можно проставить ссылку на некий виртуальный Approval, где в поле Description пояснить, что к чему.

именно так и сделали. просто может есть подходы без description.
а то через год никто не вспомнит, почему для части платежей есть апрувалы, а для другой нет

Здравствуйте, peer, Вы писали:

P>именно так и сделали. просто может есть подходы без description.
А чем description не нравится? Но можно и без него.

P>а то через год никто не вспомнит, почему для части платежей есть апрувалы, а для другой нет
Для этого есть (должна быть) документация.

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, peer, Вы писали:

P>>а то через год никто не вспомнит, почему для части платежей есть апрувалы, а для другой нет
W>Для этого есть (должна быть) документация.

как должна она выглядеть, чтобы данное изменение было легко найти, а не листать 40 страниц?

Здравствуйте, peer, Вы писали:

P>как должна она выглядеть, чтобы данное изменение было легко найти, а не листать 40 страниц?

в source control'e отмотать историю класса и посмотреть когда меняли и по какому item'у, этого достаточно. Item'ы соответствующих итераций должны хранится много лет

Здравствуйте, peer, Вы писали:

P>как должна она выглядеть, чтобы данное изменение было легко найти, а не листать 40 страниц?

Например, комментарий к данному полю таблицы. Можно и прямо в базе.

Здравствуйте, peer, Вы писали:

P>Сделали новый проект и бизнес начинает менять условия, понимая, что надо по другому.

P>Сильно упрощенный пример
P>Вот пример: в таблице Payments теперь может быть запись если есть запись в таблице Approvals по данному пейменту.
P>То есть если платеж подтвержден директором.
P>Теперь Approval становится обязательным, а раньше был необязательным и соотвествующей записи там не было.
P>Основной вопрос такой: как такие изменения внедрять и как строить архитектуру, чтобы через год можно было понять почему нет апрувала?
Хм. Наверное, это новое правило надо записывать как-то так:

(PaymentDate < new Date(2017, 10, 1) || (Payment.ApprovalID != null) // с 1 октября 2017 года платежей без подтверждения не принимаем

Здравствуйте, peer, Вы писали:

P>Основной вопрос такой: как такие изменения внедрять и как строить архитектуру, чтобы через год можно было понять почему нет апрувала?

Ну вопрос начался с описания схемы базы данных. Схема реляционной базы данных к архитектуре приложения отношения не имеет. Если вам эта мысль кажется крамольной, то остаётся только колдовать со схемой, настройками и опциями сервера бд, писать умные скрипты по миграции и переносу данных и считать себя героем.

Здравствуйте, wildwind, Вы писали:

P>>а то через год никто не вспомнит, почему для части платежей есть апрувалы, а для другой нет
W>Для этого есть (должны быть) документация тесты.
поправил

Здравствуйте, peer, Вы писали:
P>Основной вопрос такой: как такие изменения внедрять и как строить архитектуру, чтобы через год можно было понять почему нет апрувала?

— оставить FK nullable, валидацию вынести из базы. Constraints — это хорошо, но сложную бизнес-логику тащить в базу — плохо.
— добавить аппрувалы, как будто они были изначально. Использовать один аппрувал для всех не стоит, т.к. можно обжечься при удалении записи. Если заказчик хочет, чтобы старые платежи все-таки выглядели иначе (без аппрувала), добавить в аппрувал флаг и документировать его.
— воротить логику в базе. Не стоит, правда.

Здравствуйте, peer, Вы писали:

P>Сделали новый проект и бизнес начинает менять условия, понимая, что надо по другому.

>Основной вопрос такой: как такие изменения внедрять и как строить архитектуру, чтобы через год можно было понять почему нет апрувала?

Конкретное в данном случае — заведи таблицу с правилами. У правил будет OPEN_DATE, CLOSE_DATE.

Платежки должны пропускаться через эти правила.

Здравствуйте, peer, Вы писали:

P>Сделали новый проект и бизнес начинает менять условия, понимая, что надо по другому.

P>Сильно упрощенный пример
P>Вот пример: в таблице Payments теперь может быть запись если есть запись в таблице Approvals по данному пейменту.
P>То есть если платеж подтвержден директором.
P>Теперь Approval становится обязательным, а раньше был необязательным и соотвествующей записи там не было.

P>Основной вопрос такой: как такие изменения внедрять и как строить архитектуру, чтобы через год можно было понять почему нет апрувала?

Это валидатор, внешний для БД в общем случае. Например, в будущем могут затребовать что часть департаментов должна делать платежи с апрувалом, а часть департаментов — без апрува. И что тогда?

Т.е. не пытайтесь запихать это чисто в средства СУБД, напишите кодом (как хранимую процедуру или вообще C#/Java/JS, не суть). Вы ж всяко не ручками в гриде DB Manager-а создаёте записи, а через своё приложение.