Сообщение Re: Системы помнящие изменения от 12.08.2015 19:10
Изменено 12.08.2015 19:27 Somescout
Не совсем ясна задача, но возможное решение — версионирование записей. То есть вместо изменения данных создаётся новая запись и помечается как активная, все старые связи сохраняются и указывают на старую (старые) запись, все новые создаются с использованием новой версии.
В принципе даже архитектуру это не должно особо затронуть — просто перейти на работу с вьюшками, и добавить им триггеры на апдейт, которые будут реализовывать всю логику.
В принципе даже архитектуру это не должно особо затронуть — просто перейти на работу с вьюшками, и добавить им триггеры на апдейт, которые будут реализовывать всю логику.
Не совсем ясна задача, но возможное решение — версионирование записей. То есть вместо изменения данных создаётся новая запись и помечается как активная, все старые связи сохраняются и указывают на старую (старые) запись, все новые создаются с использованием новой версии.
В принципе даже архитектуру это не должно особо затронуть — просто перейти на работу с вьюшками, и добавить им триггеры на апдейт, которые будут реализовывать всю логику.
PS. Это, конечно, сложно назвать "малой кровью", но альтернативы это либо создание отдельных архивных записей (т.е. deep-copy всех связей в отдельные таблицы, или в те же но с флагом архива), либо вообще сериализация ордера в xml со всеми зависимостями и хранение в таком виде, ну или отдельное извращение когда пишутся только изменения а запись реконструируется на лету из основы и изменений (этот изврат в реляционной БД, имхо, ничто оправдать не может).
В принципе даже архитектуру это не должно особо затронуть — просто перейти на работу с вьюшками, и добавить им триггеры на апдейт, которые будут реализовывать всю логику.
PS. Это, конечно, сложно назвать "малой кровью", но альтернативы это либо создание отдельных архивных записей (т.е. deep-copy всех связей в отдельные таблицы, или в те же но с флагом архива), либо вообще сериализация ордера в xml со всеми зависимостями и хранение в таком виде, ну или отдельное извращение когда пишутся только изменения а запись реконструируется на лету из основы и изменений (этот изврат в реляционной БД, имхо, ничто оправдать не может).