Не совсем ясна задача, но возможное решение — версионирование записей. То есть вместо изменения данных создаётся новая запись и помечается как активная, все старые связи сохраняются и указывают на старую (старые) запись, все новые создаются с использованием новой версии.

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

PS. Это, конечно, сложно назвать "малой кровью", но альтернативы это либо создание отдельных архивных записей (т.е. deep-copy всех связей в отдельные таблицы, или в те же но с флагом архива), либо вообще сериализация ордера в xml со всеми зависимостями и хранение в таком виде, ну или отдельное извращение когда пишутся только изменения а запись реконструируется на лету из основы и изменений (этот изврат в реляционной БД, имхо, ничто оправдать не может).

Не совсем ясна задача, но возможное решение — версионирование записей. То есть вместо изменения данных создаётся новая запись и помечается как активная, все старые связи сохраняются и указывают на старую (старые) запись, все новые создаются с использованием новой версии.

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

PS. Это, конечно, сложно назвать "малой кровью", но альтернативы это либо создание отдельных архивных записей (т.е. deep-copy всех связей в отдельные таблицы, или в те же но с флагом архива), либо вообще сериализация ордера в xml со всеми зависимостями и хранение в таком виде, ну или отдельное извращение когда пишутся только изменения а запись реконструируется на лету из основы и изменений на заданный момент времени (этот изврат в реляционной БД, имхо, ничто оправдать не может).

PS2. Есть ещё вариант, когда сама база поддерживает историю записей и позволяет сделать запрос на указанный момент времени, но я с таким не работал. Вроде такое может oracle и sql server 2016.